> 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-<whatever>. 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ä, juolja@utu.fi |
| Laboratory of Theoretical Physics |
| Department of Physics, University of Turku |
| home: http://www.utu.fi/~juolja/ |
-----------------------------------------------
Attachment:
pgpLe4C2ul53j.pgp
Description: PGP signature