This is a short HOWTO guide for users (or previous-users) of Debian, Ubuntu or related distributions on how to guard themselves against the very serious vulnerability in Debian’s patch to OpenSSL affecting SSH, SSL and OpenVPN that was disclosed early last week. I know that many Drupal developers are Ubuntu users (though certainly second in number to the OS X users!) so I am adding this to the planet as a PSA!

If you are not familiar with this then the basic thing you need to know is that any SSH, SSL or OpenVPN keys generated after September 2006 on Debian, Ubuntu or related distributions should be considered insecure. They are insecure because there turn out to only be a very small (crypto-wise) number of possible keys that could be generated, because of a flaw introduced in random number generator seeding.

The safest thing to do is to follow step 1 below and then regenerate all SSH, SSL and OpenVPN keypairs (i.e. private and public keys) and delete all versions of old keys but most importantly public keys that you have ever placed on servers or user accounts that you access with SSH (or have setup for SSL or OpenVPN).

If this is going to be difficult (perhaps because you have lost track of where your public key may be placed) then steps 2 and 3 in the guide below explain how to check your keys against a blacklist of vulnerable keys.

Disclaimer: this is a simplified guide appropriate for people with limited exposure to this vulnerability. If you maintain complex systems or servers involving SSH, SSL, OpenVPN or related packages you will need to learn more to resolve this issue completely.

Step 1: Updating and confirming package versions

For Ubuntu you should already have received these if you have completed the update process(s) in the last couple of days. The most important ones to check (numbers for Ubuntu 8.04 only) are:

  • libssl0.9.8 should be at least 0.9.8g-4ubuntu3.1
  • openssh-client, openssh-client-udeb and openssh-server should both be at least 1:4.7p1-8ubuntu1.2
  • openvpn should be at least 2.1~rc7-1ubuntu3.2
  • ssl-cert should be at least 1.0.14-0ubuntu2.1

(version numbers from

Step 2: Checking keys on your machine

If you know of any SSH, SSL or OpenVPN keys generated between September 2006 and May 13th, 2008 on a Debian based system then you will definitely need to regenerate it (and delete the old keypair – both locally and on every machine/user you have added it to).

If you are very sure that your key was generated on another system, or was created before this date you should be in the clear. If you are not confident however then you can check it as follows:

Install ssh-vulnkey and the blacklists:
sudo apt-get install openssh-blacklist

Test your own key

If each response is “Not blacklisted”, then you are in the clear. If any response is “COMPROMISED” then you need to regenerate (and locate and delete!) all instances of this key.

If any response is “Unknown (no blacklist information)” then there is likely a problem with your blacklist installation, or your key is of a nonstandard type/length and no blacklist information is available (so you should assume it is vulnerable). One option if you get this response is to try installing blacklists for additional key types/lengths, such as openssh-blacklist-extra (‘official’, but only in Debian unstable right now) – you can download the deb package directly, which should install on all Debian and Ubuntu systems. Alternatively there is a package that Jan Tomášek put together (not official at all, but includes blacklists for the largest number of types I have seen in ssh-vulnkey format)

If you have multiple user accounts using SSH you should check them all by running as the root user
ssh-vulnkey -a

If you use ssl keys (e.g. on a Debian/Ubuntu webserver you maintain) there is a ssl-vulnkey script you can apt-get install and use in the same manner as above and a similar one for openvpn (if you use this VPN).

Note that these blacklists assume that you generated your key using the standard process (e.g. not with a tweaked key length) and on a standard system (e.g. you didn’t hack Debian to run on some weird 15 bit mainframe!).

Step 3: Checking any keys uploaded to servers

There are 2 ways to do this, the first is to copy (via scp or sftp) ~/.ssh/* from each account you have ever accessed on every server to a temporary directory your local machine and run ssh-vulnkey on the keys (you can pass in the filenames to check as parameters). Technically you would only need to do this if you have ever used a key apart from the one you already checked above or have found your key to be vulnerable in step 2 (in which case it must be deleted everywhere).

This could be done more efficiently from each server however, but is (currently) only easy to do on Debian or Ubuntu based servers.

You can do this by running ‘ssh-vulnkey -a’ as root. After doing this you could also configure the PermitBlacklistedKeys option in the updated sshd allowing you to deny access to these keys.


Always make sure that you have a secure passphrase on your key(s)!

If you need to do anything automated like an rsync backup that needs a key with no passphrase you should generate a separate key pair and only use it for this purpose, between 2 accounts dedicated to this purpose that are configured in authorized_keys to only allow execution of the specific commands needed for this operation (see man sshd under ‘command=’).

Thanks to Alexander Peslyak (better known as Solar Designer) – CivicActions’ own security and sysadmin expert for his review of this post.