Re: Heimdal and openssh
Juha Jäykkä <juhaj@iki.fi> 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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: