How-To regenerate your SSH/SSL Keys

farslayer · 05-14-2008, 08:17 AM

I'm sure everyone else is working on this today no ?

Quote:

In Debian Security Advisory 1571 (New openssl packages fix predictable random number generator), the Debian Security Team disclosed a vulnerability in the openssl package that makes many cryptographic keys that are used for authentication (e.g. through SSH) or signing (e.g. web server certificates) potentially vulnerable.

Debian has posted a wiki HOW-TO for the key regeneration process.
http://wiki.debian.org/SSLkeys

I also think the following page will be of value once it has some content..
How-To implement Key Rollover in various Debian applications

//edit: The KEY ROLLOVER page has been updated with content.

//moderator.note: WD for posting, I stickied it for the moment.

Telemachos · 05-15-2008, 08:34 AM

Here's a quick howto on generating new keys: http://www.softec.st/en/OpenSource/D...ateNewSsh.html

leibniz · 06-11-2008, 01:44 PM

I've read the security advisory and many how-tos, as well as the links in the post above.

However, when I regenerate the host keys, blacklisted keys are regenerated !

What's up with that ??

Code:

debian:~# rm /etc/ssh/ssh_host*
debian:~# dpkg-reconfigure openssh-server
Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ...
Host key 39:82:2c:e2:b0:de:88:1e:49:ff:a4:33:XX:XX:XX:XX blacklisted (see ssh-vulnkey(1))
Host key 6e:92:88:e0:de:10:03:86:60:7c:1d:b1:XX:XX:XX:XX blacklisted (see ssh-vulnkey(1))
Restarting OpenBSD Secure Shell server: sshdHost key 39:82:2c:e2:b0:de:88:1e:49:ff:a4:33:XX:XX:XX:XX blacklisted (see ssh-vulnkey(1))
Host key 6e:92:88:e0:de:10:03:86:60:7c:1d:b1:3e:ee:27:c8 blacklisted (see ssh-vulnkey(1))
.

Thoughts?

EDIT: Etch / 4.0 stable, x86_64 version. Yes, I'm up2date.

Code:

debian:~# apt-get install openssh-server
Reading package lists... Done
Building dependency tree... Done
openssh-server is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
debian:~# dpkg -l | grep -e openss
ii  openssh-blacklist                        0.1.1                                list of blacklisted OpenSSH RSA and DSA keys
ii  openssh-client                           4.3p2-9etch2                         Secure shell client, an rlogin/rsh/rcp repla
ii  openssh-server                           4.3p2-9etch2                         Secure shell server, an rshd replacement
ii  openssl                                  0.9.8c-4etch3                        Secure Socket Layer (SSL) binary and related
ii  ssl-cert                                 1.0.14                               Simple debconf wrapper for openssl
debian:~#

leibniz · 06-12-2008, 08:08 PM

Never mind. I found the problem. Thanks anyway.

farslayer · 06-12-2008, 09:09 PM

would you care to share your solution so others may benefit if they run into the same issue ?

mcs · 07-07-2008, 06:51 AM

Quote:

Originally Posted by leibniz

Never mind. I found the problem. Thanks anyway.

Hi,
I have exactly the same problem. Could you please tell us your solution???

Thank you very much
Michael

leibniz · 07-07-2008, 09:11 AM

The problem is that the Debian system was too up to date.

Downgrade libssl (and linbssl-dev, an openssl if necessary) exactly to version 0.9.8c (as noted in the security advisory) version and it should then work.

You still have to regenerate keys, but at least the system will generate good keys.

jbiggs12 · 02-25-2011, 11:55 PM

Also note that your clients might not like you suddenly switching keys with you -- last I checked, ssh won't let you connect to a server that's changed its keys unless you manually delete the stored keyfile on the client.

Marcus1981 · 04-11-2011, 09:45 AM

Hello there,

I konw this thread is rather old, but actually I've run onto the same problem.

One of my server always regenerates old/blacklisted keys.

debian etch (4.0).

up2date: not really:

Code:

apt-get install openssh-server
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut... Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder dass, wenn Sie die
Unstable-Distribution verwenden, einige erforderliche Pakete noch nicht
kreiert oder aus Incoming herausbewegt wurden.

Da Sie nur eine einzige Operation angefordert haben, ist es sehr wahrscheinlich,
dass das Paket einfach nicht installierbar ist und eine Fehlermeldung über
dieses Paket erfolgen sollte.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

Die folgenden Pakete haben nichterfüllte Abhängigkeiten:
  openssh-server: Hängt ab: openssh-client (= 1:4.3p2-9etch3) aber 1:4.3p2-9 soll installiert werden
                  Hängt ab: libssl0.9.8 (>= 0.9.8c-4etch3) aber 0.9.8c-4etch1 soll installiert werden
E: Kaputte Pakete


apt-get dist-upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut... Fertig
Berechne Upgrade...Fertig
Die folgenden Pakete sind zurückgehalten worden:
  apache2-mpm-prefork apache2-utils apache2.2-common apt-file libpri-dev libssl-dev libssl0.9.8 libtiff-opengl libtiff-tools libtiff4 libtiff4-dev libtiffxx0c2 login openssh-client openssh-server openssl passwd unixodbc
Die folgenden Pakete werden aktualisiert:
  apt apt-utils asterisk-config binutils cpio debconf debconf-i18n debconf-utils dpkg dpkg-dev dselect gnupg gpgv grub gzip initramfs-tools initscripts libapache-mod-php4 libapache2-mod-php4 libapr1 libaprutil1 libc6 libc6-dev
  libc6-i686 libexpat1 libglib2.0-0 libgnutls13 libkrb53 libltdl3 libmysqlclient15-dev libmysqlclient15off libnewt-dev libnewt0.52 libpam-modules libpam-runtime libpam0g libpcre3 libpng12-0 libpq4 libsasl2-2 libsasl2-modules
  libsnmp-base libsnmp9 libspeex1 libssl0.9.7 libtonezone-dev libtonezone1 libvolume-id0 libvorbis0a libvorbisenc2 libvorbisfile3 libxml2 libxml2-dev locales mysql-client mysql-client-5.0 mysql-common ntp ntpdate perl perl-base
  perl-doc perl-modules php4 php4-common rmail sendmail sendmail-base sendmail-bin sendmail-cf sensible-mda snmpd sysv-rc sysvinit sysvinit-utils tzdata udev vim vim-common vim-runtime wget whiptail zaptel zaptel-source
84 aktualisiert, 0 neu installiert, 0 zu entfernen und 18 nicht aktualisiert.
Es müssen 80,4MB Archive geholt werden.
Nach dem Auspacken werden 2121kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren [J/n]?

Code:

ast1:~/.ssh# dpkg -l | grep -e openss
ii  openssh-blacklist              0.1.1                                list of blacklisted OpenSSH RSA and DSA keys
ii  openssh-client                 4.3p2-9                              Secure shell client, an rlogin/rsh/rcp repla
ii  openssh-server                 4.3p2-9                              Secure shell server, an rshd replacement
ii  openssl                        0.9.8c-4etch1                        Secure Socket Layer (SSL) binary and related
rc  ssl-cert                       1.0-11                               Simple debconf wrapper for openssl
You have new mail in /var/mail/root

but as the server is in production-state for almost 4 years i don't want to update all these packets cause i fear malfunction after the upgrade and I act like "never touc a running system". let's say: all works fine except the public-key authenticaion with other servers on my network which have ssh-vulnkey installed, the affected server hasn't. maybe that's the problem. but I didn't find a way to (re-) install the binary ssh-vulnkey. can i simply copy it form another server?

thanks for your help.

greetings from germany, mainhattan

marcus

update: also the copy of ssh-vulnkey does not fix the problem. after regenerating a new ssh-key ssh-vulnkey always tells me, that the id_rsa.pub on localhost ist compromised.

so how I get the thing runnig to generate a GOOD key? I can't modify the blacklists of all my other servers cause this would lead into a security leak which would not be acceptable by the politics of my company.