As many of my readers no doubt already know, Debian GNU/Linux recently had some cryptographic vulnerability problems. By far, the most common effect of this on users of Debian will be the existence of weak cryptographic keys for OpenSSH. If you have SSH keys generated by OpenSSH on Debian or a Debian-derived system such as Ubuntu since the introduction of the Etch release, you are at risk, and should probably generate new SSH keys.

In TechRepublic’s Linux and Open Source Weblog, Vincent Danen already explained how to use the tool to solve the weak keys problem. That’s not the only way to do it, though.


When updating your openssh package on a Debian or Debian-derived system, it should automatically generate new host keys, if needed. This does not solve the problem of individual user keys, however, which must still be checked for vulnerability and, if necessary, replaced.


Since the problem was discovered and fixed in Debian, there has been a new tool added to the standard distribution of OpenSSH for Debian and derived Linux distributions called ssh-vulnkey. This tool was specifically designed to detect any vulnerable OpenSSH keys within a common range, if they exist on your system, so that you can replace them. It is installed by default when you update your OpenSSH install to a secure version.

Just run the ssh-vulnkey -a command as root to get a listing of vulnerable keys for all users on the system:

  # ssh-vulnkey -a

In the words of the ssh-vulnkey manpage, the -a option will:

Check keys of all users on the system. You will typically need to run ssh-vulnkey as root to use this option. For each user, ssh-vulnkey will check ~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/identity, ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2. It will also check the system’s host keys.

When you run that command, if you’re lucky, all keys will start with these words:

  Not blacklisted:

If you’re unlucky enough to have keys generated during the vulnerable period, you will instead see key listings that start in this alarming manner:


For all keys marked COMPROMISED:, you need to do something to fix that little problem.

There’s one other possibility, using this tool:

  Unknown (no blacklist information)

If that’s the case, you need to either just generate fresh keys to replace keys that return that result, or determine whether such keys are at risk through other means.

check creation date

If the ssh-vulnkey tool returns an “unknown” result, or if you simply want to check all your keys “manually”, you can do so. Simply track down every SSH key on your Debian or Debian-derived system and use the ls -l command to determine the creation date for the key file. Any keys generated before September 2006 are safe.

When using this procedure to check key creation dates, be careful — backup procedures and other processes that may have touched the key files may have changed the file modification time. This is not a huge problem, though. Worst case scenario: you replace a key that didn’t really need to be replaced. That’s much better than not replacing a key that did need to be replaced.

Of course, if your system’s clock is (or at one time was) off, you might get inaccurate file modification time information that suggests a key is safe when, in fact, it is not. If you have had problems with the system’s clock being off, you may wish to just replace all keys on the system. Better safe than sorry.

regenerate keys

Once you have determined what keys need to be replaced, it’s time to do something about that, using the ssh-keygen tool. For each user that needs new SSH keys generated, you first need to delete the old keys, which can be accomplished by deleting the key files:

  # rm /home/username/.ssh/id_rsa

# rm /home/username/.ssh/

Generating the new keys is easy. Make sure you’re logged in as the user whose key you want to replace to use this command:

  $ ssh-keygen

checking other systems

Any offending keys should also be deleted from the ~/.ssh/authorized_keys file on any system that may have authorized keys generated on a compromised system. In short, you should first check for vulnerable keys on your Debian or Debian-derived system, then check for their existence or authorization on any system with which it may have interacted via SSH.