Re: Heimdal and openssh

[Aaron M. Ucko]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Juha Jäykkä <[EMAIL PROTECTED]> writes:
>
>>>   * 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).
>
>> Perhaps this is THE patch which makes them all work together while
>> openssh folks claim they don't? This is a side-issue, but it would be
>> nice to know.
>
> That may very well be the case, yeah.  I've not done a lot of
> experimentation.

As I recall, that patch (which I lifted from ssh-krb5) just addresses
interoperation with old (3.5-era) versions of the "unofficial" patch,
which is otherwise stabler than the upstream-blessed gssapi support.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Heimdal and openssh

[Russ Allbery]

Juha Jäykkä <[EMAIL PROTECTED]> writes:

>>   * 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).

> Perhaps this is THE patch which makes them all work together while
> openssh folks claim they don't? This is a side-issue, but it would be
> nice to know.

That may very well be the case, yeah.  I've not done a lot of
experimentation.

> Ahem... my krb5.conf says "permitted_enctypes = aes256-cts-hmac-sha1-96"
> (in libdefaults). So this is the culprit here? [Please, do not patronize
> me on using a non-recommended config. =) It's simply that I think DES
> has no security to speak of these days. 3DES might be worth trying,
> though.]

In further discussion, this turned out to be the problem that started all
the attempts at rebuilding things (in case anyone else happens upon this
thread).  The versions of everything in sarge aren't set up to support
256-bit AES as the only supported enctype, but this will probably work in
etch.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: Heimdal and openssh

[Juha Jäykkä]

> 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.

This is more than fine for me (as long as security patches are issued in
the proper Debian way) - we use mostly Debian/stable precisely for the
reason that it changes so slowly. =)

>   * 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).

Perhaps this is THE patch which makes them all work together while openssh
folks claim they don't? This is a side-issue, but it would be nice to
know.

> > 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
[...]
> There is apparently something in your specific environment which is
> either not configured correctly or isn't working properly -- either
[moved this part a little]
> (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.)

Ahem... my krb5.conf says "permitted_enctypes = aes256-cts-hmac-sha1-96"
(in libdefaults). So this is the culprit here? [Please, do not patronize
me on using a non-recommended config. =) It's simply that I think DES has
no security to speak of these days. 3DES might be worth trying, though.]

> 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.

This is something I still do not understand: if all ssh software is
compiled against MIT Kerberos, why would *they* have trouble with AES256
keys? Stuff linked against Heimdal 0.6 probably would, like you said, but
as you said, my setup is 100% Kerberos from ssh's point of view. Unless
MIT Kerberos <1.4 do not support them any better than Heimdal 0.6 (which
does not support them at all)...

> > 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.

Ok. So it needs libsasl2-modules-gssapi-. Thanks.

> 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.

Actually, no: it was when this thread started, but 0.7.1-2 has since got
into unstable. For some reason 0.7.1-1 is still in experimental - weird.

> 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.

In retrospect, I would probably have been better off with 0.6.3, but this
has also been rather instructive, so I do not regret my choice of going
for AES keys. [And yes, I know AFS is still single-DES, but I'm not very
concerned about the filesystem - it should not have any secrets worth the
pain to crack DES. The KDC replication on the other hand...]

> 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?

I have the latter. So sshd gets me the token and nothing gets passed?
Fine. Though perhaps PAM would be better since it would get me the token
no matter how I log in? [I cannot foresee any other remote logins except
ssh; local ones are handled by kinit and pam_krb5.so. The only remote
login I can think of being relevant here is apache's kerberos
authentication, but I doubt it will make any use of the AFS.]

> Me too.  It really should all just work.

That's what Debian stable packages do - I am messing around with
self-compiled and backported beasts. Obviously a stupid thing to do. =)

Cheers,
Juha

-- 
 ---
| Juha Jäykkä, [EMAIL PROTECTED]|
| Laboratory of Theoretical Physics |
| Department of Physics, University of Turku|
| home: http://www.utu.fi/~juolja/  |
 ---


pgpkk9GgAnqXH.pgp
Description: PGP signature

Re: Heimdal and openssh

[Russ Allbery]

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 i

Re: Heimdal and openssh

[Juha Jäykkä]

> > 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

Re: Heimdal and openssh

[Russ Allbery]

Juha Jäykkä <[EMAIL PROTECTED]> writes:

> 1) Ssh-krb5 (sarge) and openssh 4.2 (sid) will not talk GSSAPI to each
> other. I gather from openssh mailing lists that no versions of openssh
> <4 and >4 will ever talk GSSAPI together due to some security patches
> made.  Thus this is not a Debian -related problem, but it leads to one.

Er, huh?

wanderer:~> dpkg -l ssh-krb5
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
ii  ssh-krb5   3.8.1p1-10 Secure rlogin/rsh/rcp replacement (OpenSSH w
wanderer:~> ssh windlord
Last login: Thu Dec 22 21:07:28 2005 from 113.110-113-64.ftth.swbr.surewest.net
 23:10:07 up 12 days,  7:22, 28 users,  load average: 0.00, 0.01, 0.00

windlord:~> dpkg -l openssh-server
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
ii  openssh-server 4.2p1-5Secure shell server, an rshd replacement

Works fine for me.

> 3) LDAP needs gssapi libraries compiled against Heimdal, not MIT
> kerberos (I assume this has something to do with the service being used
> is Heimdal, not MIT.)

No, it has to do with thread safety and is partly obsolete now that MIT
Kerberos 1.4 is in sid.  MIT 1.4 should be fine for OpenLDAP for most
purposes (although as I recall Quanah says that it has a lot of trouble
compared to Heimdal under load).

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.

> 4) Now that I have Heimdal GSSAPI libraries, openssh GSSAPI will not
> work.

Um, this doesn't make any sense to me.  Two different GSSAPI libraries,
two different library names or SONAMEs, should co-exist on the same system
just fine.  The *development* packages don't co-exist, but the libraries
do.  I have them both installed at the same time on my system right now.

> 5) As a side note: I learned afterwards that AFS token passing with ssh
> *needs* openssh compiled againsta heimdal-dev.

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.

> Now my real question: what's the smartest way to keep all these
> self-compiled packages up to date?

I'm pretty sure you shouldn't need to do any of this.  :)

> [1] MIT kerberos is not thread safe (unless my info is outdated)

MIT Kerberos is thread-safe as of 1.4.

> and only Heimdal is capable of seamlessly integrating to AFS.

MIT Kerberos works fine with AFS, but I admit that you have to go to
marginally more effort.  Not enough to deter me from using MIT, but if you
prefer Heimdal, I won't stand in your way.  :)

> The first can be worked around, but the second is probably very
> important to anyone running AFS and kerberos.

Not really.

-- 
Russ Allbery ([EMAIL PROTECTED])