Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#8373 - Make openssh kerberos-aware

Attached to Project: Arch Linux
Opened by Apollon Oikonomopoulos (apoikos) - Monday, 22 October 2007, 13:57 GMT
Last edited by Aaron Griffin (phrakture) - Friday, 07 December 2007, 02:46 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture All
Severity Low
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Openssh has a compile-time switch for including Kerberos v5 support, making secure single-sign-on possible in a kerberized domain. The upside of enabling this option is that Arch Linux can work "out of the box" in a kerberized domain (e.g. an academic institution). The downside is the added dependency of heimdal, that would move heimdal in "core" or openssh in "extra".

Additional info:
Kerberos support is enabled by passing "--with-kerberos5=/usr" to configure.
If someone considers enabling kerberos support, they could also consider including the GSS Key Exchange patch (http://www.sxw.org.uk/computing/patches/openssh.html).
This task depends upon

Closed by  Aaron Griffin (phrakture)
Friday, 07 December 2007, 02:46 GMT
Reason for closing:  Implemented
Comment by Aaron Griffin (phrakture) - Monday, 22 October 2007, 16:37 GMT
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.
Comment by Jan de Groot (JGC) - Monday, 22 October 2007, 17:04 GMT
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.
Comment by Damir Perisa (damir.perisa) - Monday, 22 October 2007, 17:25 GMT
+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
Comment by Damir Perisa (damir.perisa) - Monday, 22 October 2007, 17:25 GMT Comment by Apollon Oikonomopoulos (apoikos) - Monday, 22 October 2007, 17:29 GMT
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!
Comment by Jan de Groot (JGC) - Monday, 22 October 2007, 17:38 GMT
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 ;)
Comment by Aaron Griffin (phrakture) - Monday, 22 October 2007, 17:42 GMT
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.
Comment by Jan de Groot (JGC) - Monday, 22 October 2007, 17:46 GMT
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.
Comment by Apollon Oikonomopoulos (apoikos) - Monday, 22 October 2007, 17:48 GMT
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.
Comment by Damir Perisa (damir.perisa) - Monday, 22 October 2007, 19:38 GMT
ah, i didn't know - thanx jan for enlightment :)
Comment by Aaron Griffin (phrakture) - Monday, 26 November 2007, 20:41 GMT Comment by Jan de Groot (JGC) - Monday, 26 November 2007, 22:02 GMT
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.
Comment by Aaron Griffin (phrakture) - Monday, 26 November 2007, 22:23 GMT
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
Comment by Apollon Oikonomopoulos (apoikos) - Monday, 26 November 2007, 22:29 GMT
Works fine, both client and server. Could you also include the GSSAPI Key Exchange Patch I pointed out above?
Comment by Aaron Griffin (phrakture) - Monday, 26 November 2007, 22:36 GMT
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?
Comment by Apollon Oikonomopoulos (apoikos) - Monday, 26 November 2007, 22:54 GMT
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.)
Comment by Aaron Griffin (phrakture) - Monday, 26 November 2007, 23:11 GMT
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.
Comment by Apollon Oikonomopoulos (apoikos) - Monday, 26 November 2007, 23:35 GMT
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.
Comment by Apollon Oikonomopoulos (apoikos) - Tuesday, 27 November 2007, 13:20 GMT
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.
Comment by Aaron Griffin (phrakture) - Thursday, 29 November 2007, 18:36 GMT
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.
Comment by Apollon Oikonomopoulos (apoikos) - Friday, 07 December 2007, 00:58 GMT
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.

Loading...