Hi, This is just a quick note to let people know that I've _almost_ got Kerberos V5 working based on the patches posted to this list. I'm currently at the stage where Kerberos principals can be used to verify logins (ie Kerberos credentials are correctly passed), but I haven't (yet) got ticket forwarding to work - this is the next step! I've taken the original patches and updated then to the OpenSSH portable 2.1.0 release, replaced the calls to Heimdal specific routines, so it builds with the MIT libraries as well, and bug fixed a number of problems with the code. In particular anyone using the original patches should be careful that it doesn't check that a given principal can access a given local username, so allowing anyone with a valid principal for a domain to use -l to become any user. I'll send some patches once I've got the TGT passing working. Cheers, Simon
On Sat, 20 May 2000, Simon Wilkinson wrote:> I've taken the original patches and updated then to the OpenSSH portable > 2.1.0 release, replaced the calls to Heimdal specific routines, so it > builds with the MIT libraries as well, and bug fixed a number of problems > with the code.be very careful here. 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? :-) the KTH krb4 library used to provide krb4 support for ssh/OpenSSH never had this problem, as they make an explicit check for the setuid root case. 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. -d. --- http://www.monkey.org/~dugsong/
> 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.
> Are you also adding support for Kerberos to password authentication?Not yet. We currently use PAM to do this (as it means we can use a common ticket granting mechanism across all of our login authentication services). The patches that I'm working from do have a krb5_auth_passwd routine, but this isn't linked in to the main authentication routines anywhere. Once I've got the credentials passing and ticket granting stuff down to my, and those who get to add it to the release's, satisfaction, I'll look into adding this as well. Cheers, Simon.
Yo All! I just installed Openssh 2.1.0p2 on a Slackware 7.0 host (libc 2.1.2, kernel 2.2.13). Outbound ssh, sftp, and scp (v1 and v2) work OK to itself and to ssh 1.2.27 and 2.0.13. Inbound ssh from ssh 1.2.27 and 2.0.13 also seem OK. Inbound scp from 1.2.27 seems OK. My problem is inbound scp from 2.0.13 scp2 user at openssh:/file . hangs forever. See below for the opensshd debug output. Seems like a problem with sftp. The compiled in path on the openssh side is OK. Any ideas? RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 debug: sshd version OpenSSH-2.1 debug: Seeding random number generator debug: read DSA private key done debug: Seeding random number generator debug: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. debug: Seeding random number generator debug: Seeding random number generator RSA key generation complete. debug: Server will not fork when running in debugging mode. Connection from 208.139.26.74 port 2420 debug: Client protocol version 1.99; client software version 2.0.13 (non-commercial) datafellows: 2.0.13 (non-commercial) Enabling compatibility mode for protocol 2.0 debug: Local version string SSH-1.99-OpenSSH-2.1 debug: Sending KEX init. debug: done debug: got kexinit string: diffie-hellman-group1-sha1 debug: got kexinit string: ssh-dss debug: got kexinit string: 3des-cbc,blowfish-cbc,twofish-cbc,arcfour debug: got kexinit string: 3des-cbc,blowfish-cbc,twofish-cbc,arcfour debug: got kexinit string: hmac-md5,md5-8,none debug: got kexinit string: hmac-md5,md5-8,none debug: got kexinit string: none,zlib debug: got kexinit string: none,zlib debug: got kexinit string: debug: got kexinit string: debug: first kex follow == 1 debug: reserved == 0 debug: done read kexinit debug: kex: client->server 3des-cbc hmac-md5 none debug: kex: server->client 3des-cbc hmac-md5 none debug: Wait SSH2_MSG_KEXDH_INIT. debug: bits set: 543/1024 debug: bits set: 499/1024 debug: sig size 20 20 debug: datafellows debug: send SSH2_MSG_NEWKEYS. debug: done: send SSH2_MSG_NEWKEYS. debug: Wait SSH2_MSG_NEWKEYS. debug: GOT SSH2_MSG_NEWKEYS. debug: done: KEX2. debug: userauth-request for user gem service ssh-connection method none Failed none for gem from 208.139.26.74 port 2420 ssh2 debug: userauth-request for user gem service ssh-connection method password Accepted password for gem from 208.139.26.74 port 2420 ssh2 debug: Entering interactive session for SSH2. debug: server_init_dispatch_20 debug: channel_input_open: ctype session rchan 0 win 100000 max 8192 debug: open session debug: channel 0: new [server-session] debug: session_new: init debug: session_new: session 0 debug: session_open: channel 0 debug: session_open: session 0: link with channel 0 debug: confirm session debug: callback start debug: session_by_channel: session 0 channel 0 debug: session_input_channel_req: session 0 channel 0 request subsystem reply 1 subsystem request for sftp debug: callback done debug: channel 0: rcvd close Connection closed by remote host. debug: Calling cleanup 0x8057540(0x0) debug: Calling cleanup 0x805c49c(0x0)
> > Once I've got the credentials passing and ticket granting stuff down to > > my, and those who get to add it to the release's, satisfaction, I'll look > > into adding this as well. > > I assume that PAM still isn't available on some older platforms. Even > when it is, it would be easier for our in-house distributions of SSH if we > could have this capability statically linked in.Now available from http://www.dcs.ed.ac.uk/home/sxw/openssh/openssh-2.1.0-kerberosV.patch is a patch which implements Kerberos 5 credential passing, ticket granting and password authentication. I've built this, and tested it, with MIT Kerberos, I believe that it should work with Heimdal, but I haven't (yet) had a chance to test it. This is probably _not_ compatible with some other implementations, in particular those which overload the existing kerberos message types to carry Kerberos 5 credentials (this patch currently uses a new set of message types). I'd like to merge this code with the Kerberos 4 code so that both can coexist on the same pair of types, if anyone's interested in collaborating on this. Please take a look and let me know what you think. I'd especially welcome feedback on the ticket file checking code. Cheers, Simon.