Juha Jäykkä <[EMAIL PROTECTED]> writes: > So it seems, but your ssh-krb5 was not sarge's version.
I highly doubt that any of the changes between the current unstable ssh-krb5 and the version in sarge would have made any difference. Anyway, it works for me from sarge as well. The ssh-krb5 package is basically in deep freeze since it's likely going to get removed in favor of some sort of transition package to openssh-client. > Still, my understanding of the stuff on openssh lists is the same > despite your getting it to work. Perhaps Debian has done some > backporting? OpenSSH upstream has never worked fully and properly out of the box with GSSAPI and still doesn't. Additional patches are needed, which are in the Debian package. Looking at the changelog of openssh, I note the following: * Interoperate with ssh-krb5 << 3.8.1p1-1 servers, which used a slightly different version of the gssapi authentication method (thanks, Aaron M. Ucko; closes: #328388). * Add remaining pieces of Kerberos support (closes: #152657, #275472): - Add GSSAPI key exchange support from http://www.sxw.org.uk/computing/patches/openssh.html (thanks, Stephen Frost). which are probably divergences from upstream. > 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. Well, I don't know what to tell you. That's disturbing, since it works perfectly fine for me, from a sarge system to a system running the openssh-server in testing. There is apparently something in your specific environment which is either not configured correctly or isn't working properly -- either that, or there's something weird in my environment which is causing it to work, but we've never gotten a bug report about it that I can recall, and I'm sure other pepole are doing this. > 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? If you're using the sid openssh-server and the sarge ssh-krb5, you're using a pure MIT Kereros setup from a client perspective. >> 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?), No, it just needs some GSSAPI modules in order to do GSSAPI authentication. You can install either of libsasl2-modules-gssapi-heimdal or libsasl2-gssapi-mit, take your pick. > which needs libgssapi1-heimdal, which does not exist when using > heimdal-0.7.1. That's because Heimdal in sid is still 0.6. I expect that when 0.7 makes it into sid, the GSSAPI SASL modules will be rebuilt. > 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? I suppose, but since I really don't understand what's failing for you or why, I'm not at all sure. I'm a bit confused as to what packages you're using, what you're building them against, whether you're compiling some things by hand outside of a package build, etc. Again, my experience is that if you simply install the Debian packages as-is, they just work. You shouldn't need to rebuild or backport anything. > 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? This shouldn't be an issue. Kerberos knows how to deal with this as part of its protocol. The client, server, and KDC negotiate a shared enctype. You would only run into problems if you were using a Kerberos key that didn't have an enctype that all of your software understood. (If, for example, you had specifically configured your Heimdal 0.7 KDC to *only* generate AES keys, you would have a hard time using any software built against Heimdal 0.6. But that's definitely not a default or recommended configuration.) > 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? Do you have an AFS PAM module installed? If so, you would be getting tokens from your forwarded tickets. Or maybe you have KerberosGetAFSToken enabled in sshd_config? The AFS token passing I know about is an old, old hack that dates from OpenSSH 2, that has to be explicitly enabled when OpenSSH is compiled, and which only ever worked with protocol version one. If there's something else going on (which there may be; I've always been content with GSSAPI authentication and ticket forwarding, so I've not looked in detail), it's something else that I'm not aware of. > Thanks for a very informative answer. I'd really like to get to the > bottom of this, but that remains to be seen... Me too. It really should all just work. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>