> > 1) Ssh-krb5 (sarge) and openssh 4.2 (sid) will not talk GSSAPI to each > Er, huh? [...] > Works fine for me. So it seems, but your ssh-krb5 was not sarge's version. Still, my understanding of the stuff on openssh lists is the same despite your getting it to work. Perhaps Debian has done some backporting? And nonetheless, I still cannot make sid's 4.2p1 and sarge's 3.8 dance GSSAPI together. I just reinstalled 3.8 on the sarge box, used exactly the same settings everywhere as with backported 4.2 and no go. Simply removing that and putting backported 4.2 in place makes things work - again no changes to any configs anywhere. However, recompiling 3.8.1 against heimdal-dev appeared to make them dance. Perhaps this is a Heimdal vs. MIT issue and MIT would be the better choice here? > Anyway, LDAP just uses SASL; it doesn't link with Kerberos directly. So > you should be fine installing whatever SASL modules you prefer, whether > the Heimdal ones or the MIT ones. My mistake. LDAP needs libsasl2-modules-gssapi-heimdal (correct?), which needs libgssapi1-heimdal, which does not exist when using heimdal-0.7.1. > > 4) Now that I have Heimdal GSSAPI libraries, openssh GSSAPI will not > Um, this doesn't make any sense to me. Two different GSSAPI libraries, I was a little imprecise here. It's the backported openssh-4.2 which will not work. Again, recompiling that against heimdal-dev makes it work. This is perhaps moot now that I got 3.8.1 to work, too. At point 4) I also stated that recompiling backported 4.2 against heimdal-dev maked that work. All this makes me wonder whether this is a Heimdal 0.7.1 -issue? From what you said, I would think it should not be dependant on whether the kerberos implementation is Heimdal or MIT and that it should not matter which version of Heimdal/MIT is used, but perhaps this is not the case? For example, the default enctype in 0.7.1 is aes256-whatever, while 0.6.3 does not understand AES at all! What happens when ssh/sshd compiled against libkrb5-dev gets an aes-heimdal-token? Can this be the culprit? Does Sarge's MIT know aes? > Don't ever do AFS token passing. Pass your Kerberos tickets with GSSAPI > and then use a PAM module to get AFS tokens from your forwarded tickets. > AFS token passing is obsolete, insecure, and requires that you use > protocol version one. Uh huh? I have explicitly disabled protocol 1 from both client and server and still get afs tokens automatically on login. I didn't even do any config changes to make that happen. Some Heimdal magic here? > I'm pretty sure you shouldn't need to do any of this. :) Uninstalling all self-compiled packages and reinstalling Debian's versions breaks everything, so I am pretty sure I need to do at least a subset of this. =) I just would like to find the minimum. > MIT Kerberos is thread-safe as of 1.4. Thanks for the update. Thanks for a very informative answer. I'd really like to get to the bottom of this, but that remains to be seen... Cheers, Juha -- ----------------------------------------------- | Juha Jäykkä, juolja@utu.fi | | home: http://www.utu.fi/~juolja/ | -----------------------------------------------
Attachment:
pgpI21bIxezN2.pgp
Description: PGP signature