HOWTO: Secure your SSH, SSL and OpenVPN keys generated on Debian, Ubuntu and related distributions

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.

2017-03-31T06:20:38+00:00 Categories: Drupal, Security|

About the Author:

Owen Barton joined CivicActions as Director of Engineering in 2005. He has been developing elegant solutions in Drupal for over 12 years and is widely credited with building one of the most reputable and experienced Drupal engineering teams on the planet.

Owen serves as technical strategist, planner and innovation lead for nearly all of CivicActions’ clients. He is a strong advocate for agile methodologies, collaborative open source development, and user-driven development to help organizations achieve greater results online. Clients he has worked with at CivicActions include several federal agencies, the San Francisco Human Services Agency, and many NGOs, including Amnesty International, ACLU, Smithsonian Institution, Transparency International, American Public Media, Center for Reproductive Rights and Greenpeace.

Before joining CivicActions, Owen worked as an independent contractor and spent five years as Technical Webmaster for the Las Cumbres Observatory. Previously, he taught science and mathematics in Malawi, Africa.

Owen is an active contributor to the Drupal Security team, and co-maintains the Drush command line interface for Drupal. He has made many contributions to both Drupal core and contrib modules, ranging from accessibility improvements, through bug fixes to major new features. His work on Drupal 7 core front-end performance was sponsored by the Google “Make the Web Faster” project. He is a regular speaker and presenter at DrupalCon conferences and camps.

Owen holds a bachelors degree in Environmental Science from Lancaster University. Originally from Wales, UK, he now resides in Santa Barbara, CA with his wife and three kids. In addition to his family, Owen is passionate about local organic food, alternative transportation, international development, universal health care, climbing, photography and dancing to African and electronic music.