(and change your blogroll link to my new blog)

Doh! I knew I missed something!

Thanks very much.

http://www.ubuntu.com/usn/usn-612-2
> Once the user keys have been regenerated, the relevant public keys must be propagated to any authorized_keys files on remote systems. Be sure to delete the affected key.

Your post only mentions removing the key locally (which only prevents people accessing the ‘local’ machine) and adding the new key to servers. However, if you don’t remove the compromised key from each server that you have ever added it to, then all these servers themselves can be attacked using this vulnerability.

I have a post up at http://www.civicactions.com/blog/howto_secure_your_ssh_ssl_and_openvpn_keys_generated_on_debian_ubuntu_and_related_distributions which folks might want to look at to cross check.

I noticed about the output difference when I decided the install sshd on my machine, and I realized about the openssh-blacklist package. So this is consistent with what you mentioned (the difference between home and server).

I believe my ssh-keys where generated with red-hat based systems a couple of years ago, but it wouldn’t hurt getting new keys anyway.

cheers
Tchorix

Thanks for notifying me about this.

I figured out what’s causing this different output format. Turns out that it’s caused by a incomplete/missing blacklist for the current key type and bit amount. That you’re getting “Not blacklisted:” now, means that the key is probably indeed not vulnerable. It’s still good if you replace it though, if it was generated on a vulnerable Debian(-based) system.. you can never be sure enough ;-)

You’ll probably indeed need to install openssh-blacklist for this, as those contain the blacklists. That package apparently also wasn’t installed on my home testing system, but it was on my server. Sorry for my misinformation there. I’ll immediately correct it in the blog entry.

Also, I’ve noticed that OpenSSH will now usually reject logins by vulnerable keys, so you might have some users complaining that they’re not able to login if you manage a multi-user server, or you might lock yourself out if you update and try to login again using a vulnerable key.

Thanks for your post, but I have an observation… I tried yesterday the ssh-vulnkey command yesterday, and I got a message like yours, starting with “Unknown (no blacklist information):”.

Today I installed the package openssh-blacklist (I had already openssl-blacklist yesterday (ssl instead of ssh)) and I got a different message:

Not blacklisted: 2048 d0:c6:da:f5:e2:30:b0:3a:20:df:97:5a:47:2d:87:f0 /home/niek/.ssh/id_rsa.pub

I replaced my key for the one you published on your post… To me, this message looks clearer, becuase it states that the key is “not blacklist”… the previous message looked more like it couldn’t determined if key was blacklisted or not…

I hope it helps
cheers
Tchorix \m/

FYI, you can customize the theme to your liking with custom CSS files, if you feel like it. No need to edit the core files of K2!