An article that may have gone overlooked since it was published on Christmas by the Washington Times highlights the risks of SSH (or really any public key encryption) when you don't manage the keys and permissions those keys get you.  The article interviews Tatu Ylonen who invented SSH in 1995.  In essence, the problem isn't the technology but the management of the technology where those who deploy keys simply don't manage them.  The private keys are both in predictable locations and easily recognizable (i.e. begins with "-----BEGIN RSA PRIVATE KEY-----") if you have the correct permissions on the machine.  

The risk comes in that after keys are no longer used, they generally sit on the machine and still have access to whatever servers they were originally granted access for.  In the Linux world, combine this with .history files (for instance) and you can very quickly traverse an entire infrastructure.  Unlike digital certificates, there is no expiration date on an SSH key.

The example given in the article is essentially a data-destroying piece of malware automatically deleting data on a machine as it traverses in an intelligent way through an environment with SSH keys.  The problem is particularly acute when using keys that do not have passphrases (which is the norm).  As there is no way to know if a passphrase is required on the private key, there isn't a good policy-based way to require a passphrase-based key for access as well.

Some mitigations are requiring users to use passphrases on their private keys (and if you have the means to scan them, so much the better), regularly scanning your environment for the presence of SSH keys (grep is your friend) and limiting the locations where the private key is stored.  Of course, this only takes you so far.

If it were an easy problem to solve, (or more accurately, a solution that is not labor-intensive) it would be fixed by now.

What do you do to manage your SSH keys (or do you not manage them)?

--
John Bambenek
bambenek \at\ gmail /dot/ com
Bambenek Consulting