Arch Linux

First thing that comes to mind:
Isn't it possible to setup pam to use kerberos, and then you can UsePAM in sshd_config? That seems like the path of least resistance here. I don't want to start pulling in a lot of complex deps for something as critical as openssh.

Heimdal doesn't depend on a lot of things, it pulls in db and OpenSSL, which is a dependency for OpenSSH already.
About your pam setup: yes, you can use pam_krb5 or pam_heimdal for kerberos authentication, but then you won't have all features. pam_krb5 and pam_heimdal request a ticket for you, the success of getting a ticket means succesful authentication. You can't authenticate with the ticket on your client system using these pam modules.
Further, there's no support for key forwarding with these pam modules.
+1 for enabling Kerberos support on everything that supports it. I run a kerberized setup at home, but archlinux is not part of it.

+1
with one question: how is Kerberos v5 licenced? would it change the licence of the pkg in a way, when enabling it?
openssh is a BSD-derivate whereas kerberos implementation is i think (not sure) a MIT-derivate

http://www.pgadmin.org/docs/dev/kerberos.html

PAM is not the same thing from a security POV: with GSSAPI (read "proper kerberos") support for OpenSSH, your password never leaves your machine. It's like using public key authentication, but the keys are substituted by tickets from the Key Distribution Center (kerberos "server"). PAM on the other hand requires the password to leave your box and the authentication is performed on the remote side (i.e. the remote end has a brief glimpse of your clear-text password), thus cancelling the benefits of kerberos. I think the purpose of pam_krb5 is to be used for local logins only, to automatically retrieve kerberos credentials upon login.

I fully understand your reluctance to add extra packages to "core" and I know that this feature is really not targeted towards home users, but IMHO heimdal wouldn't be a big issue since, as JGC pointed out, its dependencies are already in "core". Of course in the end it's your decision :-)

Cheers and thank you for your rapid response!

The fact that both OpenBSD and FreeBSD contain a copy of Heimdal Kerberos in their base system tells enough about the licensing, don't you think ;)

Ok, I'll be willing to do this, but I'm no where near a security guru. I will need people to test when I put this in testing - don't expect this right away, though, I have other pending tasks.

As I have a kerberized home setup, I can test this for both client and server. You can notify me when there's an (amd64) package available.

I too have a kerberized setup at work, and I will be more than willing to help with testing. Please send me a notification as well, if possible.

ah, i didn't know - thanx jan for enlightment :)

Would someone mind trying out http://archlinux.org/~aaron/openssh-4.7p1-5-i686.pkg.tar.gz ?

Looks like it works fine, it even forwards my ticket to the other kerberized host:

Nov 26 22:57:53 kdc sshd[16644]: Authorized to jan, krb5 principal jan@GROOT.LOCAL (krb5_kuserok)
Nov 26 22:57:53 kdc sshd[16644]: Accepted gssapi-with-mic for jan from 192.168.1.1 port 34809 ssh2

Authentication without kerberos works also.

I haven't tested the server part, as I use x86_64, I tested your package from an i686 chroot.

Jan, I will build for x86_64 when I get a chance - I just built it on my 64bit box, and apparently it restarts itself as part of the build... so now I can't connect, hah

Works fine, both client and server. Could you also include the GSSAPI Key Exchange Patch I pointed out above?

I'm a bit more wary of that patch. It's one of those 'vanilla' things that never sits right if I don't know what it does.

a) What exactly does this patch do?
b) Why hasn't it been merged upstream? Looks like it has been around for a while
c) Is any functionality lost with the GSSAPI things that were just enabled?

Jan, what's your opinion?

a) What this patch does is, that when kerberos is available on a network, it uses the Kerberos "keys" of the hosts to establish the trust relationship, instead of the traditional known_hosts approach. Unlike the known_hosts approach, where you have to manually verify the key fingerprint, in a kerberized domain the Key Distribution Center offers a de-facto trust between the machines, which guarantees protection against MITM attacks and does not require the trust to be individually set up between the machines, as the KDC guarantees the trust. This is actually one of the benefits of kerberos, and there are discussions around the net stating that the gss-keyex patch actually incorporates the "correct" kerberos behaviour into openssh.
b) Can't answer that, but there are other patches as well that haven't been merged upstream (like the hpn patch for example). However, Debian seems to use the GSS Key exchange patch in their mainline openssh package and the same goes for Ubuntu (obviously) and even Solaris 10, so I expect it to have suffered extensive security auditing.
c) No functionallity at all is lost, just added. Enabling GSSAPI adds just more authentication methods the client and server will try. If kerberos isn't supported on either side, the handshake goes on with other authentication methods (public key, challenge-response etc.)

Can you please check the same URL:
http://archlinux.org/~aaron/openssh-4.7p1-5-i686.pkg.tar.gz

I have applied the gsskex patch, but am unable to test - all I can tell you is that normal SSH continues to work.

OK, seems to work fine. It can negotiate a successful key exchange with a Debian Etch host both ways. I'll see if I can get a couple more people to test it tomorrow morning.

Did some testing again today, and everything worked as expected. It's a well-tested patch, so I wouldn't expect any regressions.

Thanks once more for your response.

Ok, kerberos support is fine, but this patch is not going to work in our official package. It doesn't seem to compile on x86_64, and I don't want to hand-maintain a patch that I can't test.

I think this is a case where ABS is going to have to win out, as you're the edge case. A majority of users probably don't use kerberos, let alone for ssh, so I don't think the effort will be worth it.

Thank you once more. I understand the extra trouble this patch causes, and I agree that it's really something the average (and even advanced) user won't miss at all.