Slashdot Mirror
Kerberos Support In OpenSSH
Dan writes "Marshall Vale writes on behalf of the MIT Kerberos team and several other parties interested in the availability of Kerberos authentication for the SSH protocol. Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography. Marshall says that Kerberos support within OpenSSH may be incomplete and needs more work. In particular, implementing draft-ietf-secsh-gsskeyex in addition to any other Kerberos mechanisms will better serve the needs of Kerberos community. Secondly, he says that they would like to reduce user confusion associated with all of the different options for Kerberos and SSH. He suggests adoption of the GSSAPI key exchange mechanism in the IETF draft (which uses Kerberos to authenticate both parties to each other), in order to avoid man-in-the-middle attacks."
By the way, I've been using Kerberos in Slackware Linux in 1996. Does it fell to your definition of "forever"?
Less is more !
Moderators on crack again?
Unix systems have had Kerberos forever, via both commercial implementations and the MIT reference implementations. Linux DISTRIBUTIONS largely haven't had them, but that's because of the hassles with US export controls in place until recently. Anyone likely to use Kerberos also knew how to build the MIT reference implementation from scratch, if necessary.
Windows is actually a "Johnny-come-lately" - I had been working on unofficial Debian packages of the MIT Krb5 packages for about 3 years when MS announced Windows would use Kerberos in new products, and as usual they attempted to add their own unpublished proprietary crap to it. I (and many other people) didn't mind them adding add'l field specific to the W2K client model, but there was no need for the initial draconian non-disclosure policies.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
there exists kerberos authenticated SMTP and also kerberos authenticated POP (KPOP). both are in use at MIT, but the former is a relatively new service.
GET YOUR WEAPONS READY! --DR.LIGHT
Yes it is BSD, it's an OpenBSD project.
Spyder
i have a mod for putty that can do gssapi+kerberos auth for users. windows client to the linux/unix openssh servers.
we're beta testing (or will start soon) but it works!
respond if you're interested...
...or maybe not.
I believe recent Kerberos for Windows distributions from MIT include ms2mit.exe, which you can use to do that conversion.
MIT has single-signon working (the conversion happens automatically) but I don't know if they released the code.
The main advantage of using Kerberos for key exchange is the elimination of the known_hosts file, and the tendency for ssh users to accept any
old key offered by the server the first time they connect. This common behavior exposes the user to the risk of man-in-the-middle attacks. If I've tricked your stack into connecting to me instead of the host you thought you were getting, I can spoof both ends of the connection and intercept your traffic in the clear. Also, Kerberos authentication is two-way (server to client AND client to server)
"Even if you are on the right track, you'll get run over if you just sit there" - Will Rogers
Absolutely agreed.
From what I've seen, the main reason people use telnet etc. is simply because it's enabled by default. They are too clueless to install SSH (and often too clueless to enable telnet if it were disabled), sometimes they haven't even heard of it.
Many open source OS distributions (at least the *BSDs, probably most if not all Linux distributions) already include SSH and disable almost everything in inetd.conf by default.
MacOS X also includes (but doesn't enable) SSH and disables everything in inetd.conf, and only makes SSH easy to enable (checkbox in the system configuration app).
But Solaris, HP-UX, AIX, Tru64...no such luck (disclaimer - I haven't looked at the most recent versions of some of those systems).
Well, Pop3 can be fairly secure, pop3 over ssl.
I have my own SMTP & pop3 server, and I have compiled my POP3 daemon with ssl support, and I use outlook to connect, securely on pop3, at least no cleartext password exchange there.
Althought it doesn't change anything in the man-in-the-middle problem.
One problem only, as the SSL certificate has been signed by myself, when outlook reconnect to the server first time it is run, it says the certificate is unknown.
There are other parties interested in Kerberos?
Yeah, most large Universities.
Finkployd
Yes. Many of them.
SSH is great for what it does, but it really doesn't do that much. Most people don't notice this since they don't need it to do much - for them it's just a better telnet.
But it scales horribly, look at the other comments.
Worse, SSH drops authentication information. This doesn't sound like much until you've worked in an environment where clients and servers can perform mutual authentication "beneath the surface," but once you have going back is painful.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
If you're deploying SSH in an environment that already uses Kerberos, there absolutely is an advantage. GSSAPI external key exchange means that, if you're authenticated to the Kerberos realm, you have tickets that will let you connect to any other machine in the realm (or in a trusted realm) without having to do out-of-band verification of the RSA key's fingerprint.
With traditional RSA key authentication in SSH, the security of the SSH connection requires that either the user is diligent enough to check every new RSA fingerprint when it pops up, or that the site admin has stored all of the machine fingerprints in /etc/ssh/ssh_known_hosts. With Kerberos, mutual authentication is done for you. This is a very big advantage for anyone with a lot of machines, particularly if Kerberos is in use anyway.
kerberos authentication via gssapi in openssh was available in linux before it was available in windows. i know, cause i did some of the work.
...or maybe not.
OpenSSH has also been modified to support the Grid Security Infrastructure (GSI) used by Globus.
The ssh-krb5 package has been in debian for, well, years... it works OK .. ironically I'm ditching kerberos soon because it's a lot of hassle, since the token keeps expiring at precisely the wrong moment just as I want to do something, plus it's difficult to switch users since you can only have one ticket at a time - PKI with forwarding is a lot easier.
I am unable to get to the article (slashdotted) but there is an already existing GSSAPI patch for OpenSSH here: patch.
.. is two doors down on the left.
$ find
Kerberos authentication has been in openssh for a while, IIRC. What openssh lacks is kerberos ticket passing. Authentication works by validating your kerberos ticket against a KDC, or validating your password against the KDC. #2 has been there. I believe #1 has as well. Ticket passing allows your ticket to be forwarded to the next server, so you can *again* login in to another system. If you don't pass tickets, you need to kinit on each system before you can ssh.
And BTW, kerberos 5 sysadmins can disable non-encrypted services, so rsh/rlogin/telnet/ftp/etc can mandate encryption or fail the connections.
Kerberos is used (although not as uniformly as might be wished) in a few decent remote filesystems as well. This can be a real boon for such setups (which should be more common, IMHO). Without it, you can get a secure login to a remote machine, but still need to provide that machine with an authenticator for secure network services (such as afs, nfs, ftp, imap, etc.).
At MIT, at least a year or two back, we had people using a mixture of ssh and kerberized rlogin just to deal with the ticket-forwarding issues.
Now all they have to do is make Kerberos as easy to install as openssh. Last time I had to deal with kerberos, it was like removing my own spleen. And it never even worked well when I used it -- like most other MIT standards, it was a pig and had an archaeic interface. And the expiration mechanism still sucks.
I've finally had it: until slashdot gets article moderation, I am not coming back.
Yes, Non-MS kerberos systems will ignore the MS data in the Kerberos ticket and accept it as authentication if you are part of a Kerberos realm that uses a MS KDC. For example, OS X can use an Active Directory server as a KDC and pass the TGT to a cyrus IMAP server. The IMAP server will ignore the MS junk in the ticket and as long as you check out, you can get your mail. The problem is going the other way. You cannot, get a TGT from a MIT KDC and pass it to a MS Kerberized service.
Sadly, recent implementations of MIT Kerberos automatically reverse DNS names. So, if I can spoof the user's target DNS name to point to my blackhat machine, the Kerberos libraries will cheerfully reverse my IP address to get the Kerberos principle for authentication.
But what does that buy you? I assume that a KDC must encrypt part of it's reply with the host principal's secret key that must also be stored and read from a local keytab file that typically only root can update. How can you spoof this part of the validation?
One must understand the rationale for developing opportunistic encryption. It is not to provide for secure communication. It exists to clog the spooks' sniffers with as much unusable data as possible. There is a distinction there. Yes, for the purposes of the data contained within that IPsec payload the result is the same, but users would be absolutely insane to switch from ssh to telnet+opportunistic IPsec and expect the same level of protection.
IPsec in general is a very different story, and something that I use extensively in production.
noah
There's KRB5/GSSAPI/IMAP support in Ximian Evolution nowadays. You need version 1.2.4 or later. It's enabled in the binaries for RHL9 from Ximian. A nice single-sign-on mail solution for sites with a Kerberos infrastructure.
The problem is that the current version of OpenSSH does an aklog with krb4, which may or may not work without additional patching (i.e. changing the aklog code to use krb5) depending on how your sshd handles the krb libs.