What to do about the Debian bug weakened SSH keys?

Slashdot is discussing a bug in SSH key generation which was introduced into the Debian source tree in late 2006 that has just been uncovered. Essentially someone removed the random seeding from key generation making keys guessable. See:

http://it.slashdot.org/it/08/05/13/1533212.shtml

Now, what do we need to do with our linodes to correct for this?

17 Replies

Switch to Gentoo :-)

@vca:

Now, what do we need to do with our linodes to correct for this?
Upgrade OpenSSL and re-generate all your SSH and SSL keys.

@dfelicia:

Switch to Gentoo :-)
or slackware, or centos, or arch, or fedora, or suse, or mandrake…

It may be worth noting that the error was introduced in September 2006, and keys older than that should be fine.

Does this apply to gnupg keys as well?

@bdonlan:

Does this apply to gnupg keys as well?

No, in the Debian announcement:

http://lists.debian.org/debian-security … 00152.html">http://lists.debian.org/debian-security-announce/2008/msg00152.html

they said:

"Keys generated with GnuPG or GNUTLS are not affected"


Stephen

> or slackware, or centos, or arch, or fedora, or suse, or mandrake…

Heh. Reminds me of a comment I enjoyed at the top of efudd's script from this thread:

# Installation Tips:
# gentoo: emerge XML-LibXML ....
# debian: install gentoo OR apt-get install libxml-libxml-perl
# redhat: install windows
# slackware: rock on! 

apt-get update

apt-get upgrade

http://www.us.debian.org/security/2008/dsa-1571

:)

@CoreDuo:

apt-get update

apt-get upgrade

:)

That gives you the fixed software. That doesn't fix the existing weak keys (including host keys) or certificates that may have been generated. What fun!

Updating SSH host keys:

rm /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server
/etc/init.d/ssh restart # might not be necessary

Obviously you will receive host key mismatch warnings after this. Replace the relevant key(s) in ~/.ssh/knownhosts with the key in /etc/ssh/sshhostrsakey.pub on the server (copy down the value using your existing session).

Don't forget to update lish keys as well, if you're using debian/ubuntu locally!

Don't forget that if you generated a certificate request with a compromised Debian-based distro, you'll need to replace your certificate. Hopefully that won't mean having to pay again…

@SteveG:

@CoreDuo:

apt-get update

apt-get upgrade

:)

That gives you the fixed software. That doesn't fix the existing weak keys (including host keys) or certificates that may have been generated. What fun!

This will fix the keys on Ubuntu. They added on an "openssh-blacklist" package that comes with the upgrade. It will check and offer to regenerate keys during the upgrade action. It also provides a "ssh-vulnkey" utility to allow users to check their individual keys. Not sure if Debian has the same thing, but I wouldn't be surprised if that's where it came from.

http://wiki.debian.org/SSLkeys

This is the best page I've seen on the matter. It describes how this issue affects different packages you might be running, the use of ssh-vulnkey and dowkd.pl for testing keys, how to test SSL certificates, etc etc.

And you don't have to be running Debian at all to be affected. Basically if you've used a good key to talk to a machine with a bad key, your key may have been compromised.

> * key generated with broken openssl = bad

** key generated with good openssl and used to ssh from a machine with bad ssl = bad*

  • key generated with good openssl and used to ssh from a machine with good ssl = good

@path:

@SteveG:

@CoreDuo:

apt-get update

apt-get upgrade

:)

That gives you the fixed software. That doesn't fix the existing weak keys (including host keys) or certificates that may have been generated. What fun!

This will fix the keys on Ubuntu. They added on an "openssh-blacklist" package that comes with the upgrade. It will check and offer to regenerate keys during the upgrade action. It also provides a "ssh-vulnkey" utility to allow users to check their individual keys. Not sure if Debian has the same thing, but I wouldn't be surprised if that's where it came from.

I had to do 'sudo apt-get update && sudo apt-get dist-upgrade' to get the full set of updated openssh packages since a few were held back otherwise.

as a point of reference: this is the reason that major vendors dont usually accept patches ad-hoc.

Something like this company wide would be a major PITA.

@tronic:

I had to do 'sudo apt-get update && sudo apt-get dist-upgrade' to get the full set of updated openssh packages since a few were held back otherwise.
How can I tell whether OpenSSL was upgraded when I did this? I still get the following results:

  # ssh -V
  OpenSSH_4.6p1 Debian-5ubuntu0.5, OpenSSL 0.9.8e 23 Feb 2007

  # openssl
  OpenSSL> version
  OpenSSL 0.9.8e 23 Feb 2007

Those are the same results I got before I upgraded. Does that mean that I'm not running the new versions, or is there some sub-version information that isn't printed? Something definitely did change, because is now installed, and it runs.

Yes, there is deb package specific version info that won't show up in the vendor commands. Try 'dpkg -l openssh-server', or look in the Debian changelog for the package. For example:

$ dpkg -l openssh-server

||/ Name Version Description

+++-==============-==============-============================================

ii openssh-server 1:4.7p1-10 secure shell server, an rshd replacement

The part after the dash (-10) is the Debian specific release number. It says this is the 10th version of the Debian package for openssh 4.7p1.

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct