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

Comments

RSA?

[paranode]

Is there any advantage to using this over the already-usable RSA key authentication in SSH?

Re:RSA?

[Mark Bainter]

Yes. Scenario: 500 *nix servers, team of 10 administrators. Solution 1: Each user gets a login created on each machine, and then they login, create an ssh key, and distribute the public key to all other machines. Later, when that person leaves, all those keys and all those user accounts get deleted. (Given, you could use NIS/LDAP/etc to try and alleviate the user-account side of the issue. But you didn't mention that as part of your RSA solution, and note that each of these solutions has potential inherent security problems.) Solution 2: Setup kerberos. Authenticate all users for all machines securely from one location. Add and delete user accounts from one location.

Re:RSA?

[More Trouble]

Solution 2: Setup kerberos. Authenticate all users for all machines securely from one location. Add and delete user accounts from one location.

Depends what you means by "accounts". Any way you look at it, you'll want to set up something like LDAP for distributing the equivalent of /etc/passwd data. Kerberos gives you user authentication, and the ability to disable user accounts globally -- though not within the ticket lifetime! Kerberos doesn't give you much in the way of provisioning accounts, which is what your statement implies.

:w

Re:Time for Linux to catch up?

[tempmpi]

Linux has had Kerberos and IPSec for long time, too. This is not a Linux vs. Windows thing, it is about the best way to use Kerberos authentification for SSH.

Re:ssh and telnet

[Anonymous Coward]

We'd also better disable ESMTP and POP3 too. You don't mind waiting for your mail while we write a secure replacement, do you?

Re:ssh and telnet

[Surak]

Secure IMAP with Kerberos support. :-P

Re:ssh and telnet

[jarkko]

All UNIX and Linux distros should have cleartext protocols disabled by default.

I still use telnet, ftp and even rsh as well and I don't feel insecure about it. Transport-mode IPSec between hosts really helps a lot here...

The "moronic passwords"-issue comes mainly from pop3 and different web-sessions these days. What the world really needs is opportunistic IPSec.

Re:ssh and telnet

[isa-kuruption]

I will paraphrase a quote from Mr Bruce Schneier:

"No matter what security measures you implement, the end users are still the weakest link in the chain."

I think it speaks for itself. Passwords can be brute forced via secure protocols as well. Passwords can be copied from stick-it notes on people's monitors, or from knowing their maiden name.

While cleartext protocols should be disabled, many places use them... a LOT. And while I know SSH can replace most of their functionality, many places have scripts that have been running for years that would need man power to rewrite (even if changing only one line) which makes it difficult for many organizations decide this is a priority.

Heck, I had a hell of a time convincing our organization to move from SSHv1 to SSHv2 due to the man-in-the-middle attacks.

Re:ssh and telnet, sftp and ftp

[Endareth]

I think telnet and ftp should be disabled across the world with very limited exceptions. All UNIX and Linux distros should have cleartext protocols disabled by default.

I would agree 100% with this, some *NIX flavours do this already, notable NetBSD and OpenBSD, and I suspect FreeBSD does also, though TBH that's guessing. With SSH available there really is no need that I can think of off hand (I'm sure someone can think up a counter argument) for telnet to still exist, and the only reason for plain ftp to still exist is because all those fully featured ftp clients (download managers, resumers, etc) are implemented with plain ftp instead of sftp. If they are well enough written however, it shouldn't take much effort to re-write these to use sftp instead. While Kerberos is a definate improvement, the difference between telnet and SSH is far huger than the difference between SSH without Kerberos and SSH with Kerberos.

Re:ssh and telnet

[ave19]

Would it be more accurate to say, you wish to see all cleartext services disabled by default? Since ftp, telnet, rlogin, etc. all have ciphered, non-cleartext authentication methods with mutual authentication?

Where I work, we allow kerberized telnet, but not cleartext telnet. Same for ftp.

-ave

Re:ssh and telnet

[iabervon]

You really mean cleartext authentication, not cleartext protocols. Cleartext ftp is fine for anonymous downloads; cleartext HTTP is fine so long as you don't use passwords or authentication cookies (note that you and I are both posting in violation of what we're saying. But anyway...); cleartext telnet is fine for rainmaker.wunderground.com; and so forth.

I find it odd that systems package together telnet (a nice wrapper for TCP, with a few extra features; very useful for a number of things, including getting the weather) with telnetd (a program for providing shell access to attackers, simply based on the few extra features over TCP. Similarly ssh and sshd. Programs that make connections are very different from programs that provide shell access.

Personally, I think Linux distros should have remote login disabled by default. Anyone who actually wants it will know how to enable it, and will hopefully pick a sane protocol to use to do so.

Man-in-the-middle

[smallpaul]

I often hear about man-in-the-middle attacks in theory but I've heard of one in practice. Can someone point me to some documentation about an incident where data was compromised by a MITM?

Re:Other parties?

[azimir]

Yes, the OpenAFS guys use it for authenticating users of AFS mounts. Getting Kerberos working is vital to a third-party ticket/key/token/whatever system right now.