02:59 pm, 14 May 08
what you need to do in response to the openssl fiasco
If you have used a Debian-based system to generate SSH keys in the past two years, your keys are likely no good. This document has instructions. In brief:
1) Delete your bad keys:
2) Update your systems. I see an "openssl-blacklist" package show up on both my Debian stable and my Ubuntu whateverletterthey'reon one. You'll get some debconf prompts about it clobbering stuff, including potentially your host keys, which means the next time you connect to the machine you'll get the "host keys have changed" message.
3) To make yourself feel less anxious, try running
1) Delete your bad keys:
.ssh/id_*. Fix all systems where you're trusting those keys (think .ssh/authorized_keys); someone has already published a table of all private keys, so it's just a matter of time before your system is brute-forced.2) Update your systems. I see an "openssl-blacklist" package show up on both my Debian stable and my Ubuntu whateverletterthey'reon one. You'll get some debconf prompts about it clobbering stuff, including potentially your host keys, which means the next time you connect to the machine you'll get the "host keys have changed" message.
3) To make yourself feel less anxious, try running
ssh-vulnkey to print an analysis of keys in standard paths on your system. (Run it as sudo ssh-vulnkey -a to check all users on your system.)
The other line of code (in ssleay_rand_add()) was incredibly important -- without it, ssleay_rand_add is basically a no-op!
Removing the public keys
Shouldn't you also remove your public keys from all authorized_keys where you've copied it to? What if you upgrade sshd those machines as well - does the updated sshd actually special-case (ignore) weak keys (and thus removing the need to remove your public keys)?Re: Removing the public keys
That's step one in the steps I wrote.