Tag Archive for 'debian'

How to deal with the recent random number generator bug in OpenSSL and update your SSH keys.

Edit: 16 may 2008: Please read this correction, if you’ve already read this article.

Edit: 19 may 2008: Doh! Also forgot to mention that you of course need to remove your vulnerable keys from any systems you uploaded them to. You can do this by removing them from your ~/.ssh/id_rsa file (see this comment for more info). Guess that teaches me about getting posts out in a hurry. Luckily, most upgraded SSH servers currently detect most compromised keys, so your compromised keys will usually be rejected.

You may have heard of the predictable random number generator bug in Debian and distributions based on Debian (like Ubuntu).

Those of you using SSH to log in to other systems are probably mostly affected by this, so here is a quick tutorial to get you back up and running:

First, make sure you upgrade your system. This is a prerequisite before fixing your SSH keys. On most Debian-based systems, your update process will be like this:

apt-get update
apt-get upgrade

You might need to add sudo before both commands if you’re not root and are on a system that allows you to sudo to root.

Presumably, your system will list that some SSL packages will need to be updated, so run the upgrade.

Your system might ask you to restart some processes, and recommend that you reboot. I’d recommend following up to this advice and just restarting your system, but if you really can’t, make sure you at least list the processes that make use of OpenSSL on your system to be restarted.

Next, depending on if you’re using Debian stable or unstable, or another distribution like Ubuntu, you might have a new application called ssh-vulnkey.

Simply running it without any arguments will try to determine if your SSH key is vulnerable, if you have any. Note that this might yield false negatives, so it’s best to replace your SSH keys anyway, but if you want to take the risk, that’s fine with me.

The output will be somewhat like this:

Unknown (no blacklist information): 2048 d0:c6:da:f5:e2:30:b0:3a:20:df:97:5a:47:2d:87:f0 /home/niek/.ssh/id_rsa.pub

Correction (16 may 2008): your output should look like this (this is important, because else the blacklist checker doesn’t have a good blacklist for your key):

Not blacklisted: 2048 d0:c6:da:f5:e2:30:b0:3a:20:df:97:5a:47:2d:87:f0 niek@lithium

You might need to install openssh-blacklist for it to show up like that, which you can do like this:

apt-get install openssh-blacklist

This presumably means that your key is not vulnerable. You still might want to generate a new one anyway (better safe than sorry, right?)

If you choose to generate a new SSH key, then first back up your old one:

mv .ssh .ssh.bak

Next, we can safely generate a new SSH key, just run:

ssh-keygen

and follow the interactive prompt.

Next, you might need to tell your servers about your new SSH key, but you just made a new one! Luckily you backed up your old key though, so you can still log in to your server like this:

ssh -i /location/to/the/backup/of/your/keyfile/here (presumably ~/.ssh.bak/id_rsa) yourserver.invalid

Next, put your new public key (which probably is in ~/.ssh/id_rsa.pub on your home system) in ~/.ssh/authorized_keys on your server, and log out. Now try to log in again with your new SSH key.

The host key(s) of your OpenSSH server might also be vulnerable, you can check this by issuing the following commands (obviously replacing yourserver.invalid with your actual SSH server):

ssh-keyscan -t rsa yourserver.invalid|ssh-vulnkey -
ssh-keyscan -t dsa yourserver.invalid|ssh-vulnkey -
ssh-keyscan yourserver.invalid|ssh-vulnkey -

Note that some of these might not work, depending on if your server has a host key with the algorithm we’re checking for.

The Gentoo wiki has a howto on how to generate host keys should you find yours vulnerable, or decide to update them anyway. Remember to restart your SSH server after updating those, and remember that you will probably get a complaint from your SSH client next time you try to login to your remote system that the host keys have changed.

Disclaimer: please note that I’m not ( currently at least ;-) ) a security or cryptography expert in any way, and some of my advice may be slightly incorrect or just wrong. This information is provided as is, without any warranty. Please contact a real security expert if you feel more secure with that, and don’t blame me if something goes wrong. Feel free to submit corrections in comments, and I’ll try to correct any blatant factual errors.