TOM KEMP'S CENTRIFY BLOG

How Secure Is Your OpenSSH?

Friday, March 14, 2008

Recently one of our developers was visiting a customer and he told me the story that when one of the sys admins he was working with gave him a hostname to ssh to, he was presented with the following message:

 
The authenticity of host 'hostname (172.27.20.32)' can't be established.
RSA key fingerprint is 37:58:49:7b:da:8c:a9:61:44:3f:5c:35:81:20:b1:ff.
Are you sure you want to continue connecting (yes/no)?

Our developer then immediately asked everyone in the room to check their "valid host RSA key fingerprint list" to see if this was a valid key, and they all had a good laugh.

Not being a developer but one to be technically curious, this led me to ask "what is a RSA key fingerprint?" and "what actually happens when you ssh into a remote system?" Below is a summary of what I learned, but in the description I got back it helped me better appreciate the value that Centrify DirectControl provides vis a vis OpenSSH.

So what is going on when you ssh into a system?

When the OpenSSH daemon is run for the first time on a system, it generates a public and private key pair to identify the current host on that machine. In a secure environment, system administrators collect the public keys from all the OpenSSH hosts, and securely deliver them to their user community in the form of a file for ssh UNIX clients, or a set of registry entries for Windows PuTTY users. In theory, you could also check the above fingerprint against a printed list or web site. Of course, this list must be updated whenever a new host is added to the network.

In practice, it turns out few system administrators have the time to manage this, nor can users be trusted to check a list, hence most companies allow users to blindly answer yes to the above question (which we can assume most do), thus security is completely dependant upon trusting the network integrity. It turns out it would be trivial for a intruding computer on your network to highjack an IP address, and present a similar RSA fingerprint prompt to your users, and easily start capturing usernames and passwords. As with all security software, OpenSSH is only as secure as your deployment practices dictate.

DirectControl and Kerberos to the rescue!

Now you probably already know that using OpenSHH with Kerberos provides users with single-sign-on capabilities, without having to maintain user public and private key pairs, and exchange them between machines. But Centrify has further extended OpenSSH and PuTTY to use Kerberos GSS key-exchange to authenticate the remote host computer. Not only does this mean the user is no longer presented with a ridiculous RSA fingerprint question, but the remote computer is authenticated and verified using it's own Kerberos credentials. In this configuration, administrators no longer need to track and distribute RSA public keys, and intruding computers which are not members of the domain cannot perform the GSS key exchange. See this blog entry for how our PuTTY and OpenSSH works.

DirectControl still works with native OS versions of SSH and Putty, but some do not correctly support Kerberos single-sign-on, and very few currently support GSS Host Key Exchange, though there are patches available in the wild which add these features. Centrify is continuing to improve both PutTTY and OpenSSH and provide administrators improved group policies and tools to better control the security of their systems. For example, DirectControl's OpenSSH group policies include: controlling who is allowed to SSH to a set of computers; controlling the time allowed for a successful login; displaying a security notice at login; and preventing root user login via SSH. Centrify is in fact the only vendor to offer Group Policy management of both the client (PuTTY) and server (sshd) component of SSH.

Net net is that Centrify offers not only a value proposition of providing pre-packaged versions across dozens of platforms of the latest OpenSSH and PuTTY that have been Kerberized (and tested! and you can even buy a support package from Centrify for this open source solution), but by enforcing the use of Kerberos it makes OpenSSH more secure for the reasons I spelled out above. Also, through DirectControl's Group Policies for OpenSSH it makes OpenSSH even more manageable by IT staff. Finally, another key benefit is that system administrators can now silently authenticate from their Windows PuTTY into a UNIX system (i.e. do not have to enter a username/password each time as their valid Kerberos ticket they got on their Windows desktop is accepted by UNIX systems running DirectControl), saving time and repetitive typing. Sounds like a big win all around!

 
[Many thanks to Mike Patnode, our VP of Technology, for helping me with this blog entry.]

< Previous Article: Startup Superstar - Our Own Paul Moore
> Next Article: Java and J2EE Integration with Active Directory