> > 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ä, [EMAIL PROTECTED] |
| home: http://www.utu.fi/~juolja/ |
-----------------------------------------------
pgpLK59bYikGT.pgp
Description: PGP signature
