It's 3pm 2 days after Christmas, do you know where your unmanaged SSH keys are?

Published: 2012-12-27
Last Updated: 2012-12-27 21:21:08 UTC
by John Bambenek (Version: 1)
4 comment(s)

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

4 comment(s)


I only generate keys without passwords for very specific uses (usually crontab) and use the command=".." option in authorized_keys on the receiving system to limit the damage they can do. And 'keychain' can be an option to have keys available to running processes without having a private key file without passphrase on disk.
Had this discussion couple months ago with external IT audit. Told them that .ssh key files are readable b
Had this discussion couple months ago with external IT audit. Told them that .ssh key files are readable by the same people who would know the long complicated password.
Passwords might be more secure in an internal environment, as we seem to change those once in a while, while thousands of employees might have a copy of the ssh key we never change.
Changing the ssh key is way easier, you can have multiple active at the receiving end on the same account.

The lessons: Unmanaged stuff tends be be / become insecure.
Sometime last year I started investigating extending the schema on our OpenLDAP server to allow users to store the public key of an ssh certificate there. The idea was that I'd have a job that would periodically use LDAP to govern which users could access which role accounts on which servers via their ssh certificates. And that job would then remove any ssh public keys from various authorized_keys files that couldn't be found (or weren't in the appropriate LDAP groups).

The proof of concept worked fine, but it never got rolled into production. Other folks in my group weren't ready to consider having access control (at least via ssh) governed by LDAP group objects. (sigh) Oh well... Someday...

Diary Archives