Kerberos V5 integration

[Simon Wilkinson]

> i've not looked at heimdal, but the MIT krb5 code has historically had
> very bad interactions with the ssh-1.2.2x implementation, such that an
> unprivileged user could manually set their KRB5CCNAME environment variable
> to use someone else's ticket file, and the setuid root ssh client would
> happily comply (which is why tatu disabled krb5 support in the official
> distribution). let me know if this still works? :-)

Yup. You need to check that the ticket file is owned by and readable by
the user who invoked ssh, not just that you can access it. I'm using a
check on the ticket file before I pass it to the krb5 libraries.

> we also need to find a way to make krb4 and krb5 support interoperate. in
> my original krb4 patch, i added version information to the ticket
> encoding, which glenn machin didn't use in his krb5 port to distinguish
> Kerberos types. we may be able to support both versions with a simple
> failover instead.

Yes. The code that I've built from appears to add two new message
types -

#define SSH_AUTH_KRB5           29
#define SSH_PASS_KRB5_TGT       30

which it uses for Kerberos 5 support. In its original state ticket granting
didn't work. I've now reworked this so that it works, but only if the TGT
message comes before the AUTH one. This is all rather nasty at the moment,
but it works.

Once I've got the simple case going, it would be nice to look at collapsing
back into a form that doesn't require protocol extensions like these. At
present, I can authenticate a session using credential passing, and forward
credentials. I'd quite like to add support for destroying forwarded 
credentials at log out as well. I'll probably tidy up and post the patches
for review tomorrow.

Cheers,

Simon.