Freitag, 16. Mai 2008

Unsichere ssh-Schlüssel in Debian

Es ging durch die Presse: Debian und auf Debian basierende Linux-Distributionen wie Knoppix oder Ubuntu generieren ssh-Schlüssel auf eine Art und Weise, die es relativ einfach macht, solche Schlüssel zu knacken.

Updates der OpenSSL-Bibliotheken sind mittlerweile über die verschiedenen Paketmanager verfügbar , aber was macht man mit mit den korrupten Schlüsseln?

Am besten neue erzeugen :-)

Erstmal ein paar Links zum Einlesen, hier die offizielle Seite für Debian:

http://www.debian.org/security/key-rollover

Auch Heise berichtete: http://www.heise.de/newsticker/Schwache-Krypto-Schluessel-unter-Debian-Ubuntu-und-Co--/meldung/107808

Wenn man also mittels

//NSLU2~# apitude update
//NSLU2~# apitude upgrade

die aktuellen Updates eingespielt hat, muss man in meinem Setup (ssh nur mit privaten Schlüsseln) neue Schlüssel erzeugen (je nach Hardware dauert das Generieren einen Moment):

//NSLU2~# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/root/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 root@NSLU2

So, neuer Schlüssel ist da:

//NSLU2~# cd .ssh
//NSLU2~/.ssh# ls -l
insgesamt 16
-rw------- 1 root root 392 2008-05-16 16:17 authorized_keys
-rw------- 1 root root 1751 2008-05-16 16:30 id_rsa
-rw-r--r-- 1 root root 392 2008-05-16 16:30 id_rsa.pub

Da man nicht wissen kann, welche Schlüssel wirklich von der Lücke betroffen sind (außer man nutzt ssh-vulnkey, das es aber anscheinend für Debian auf ARM/NSLU2 nicht gibt), sollte man die gesamte "authorized_keys" löschen. Oder man macht das nacheinander, so wie jetzt beschrieben:

In meiner Datei ist nur ein Schlüssel vorhanden, mit dem befinde ich mich von meinem Windows-PC und putty gerade auf der Slug. Also tragen wir erst den neuen öffentlichen Schlüssel zusätzlich ein:

//NSLU2~/.ssh# cat id_rsa.pub >> authorized_keys  

Jetzt transferieren wir den privaten Schlüssel (id_rsa) irgendwie auf den Rechner/PC, von dem wir mittels ssh zugreifen wollen. Unter Windows wird das meist mit putty erfolgen. Hier muss man den privaten Schlüssel in das putty-eigene Format umwandeln. Dazu startet man im putty-Verzeichnis die PUTTYGEN.EXE.

Dort öffnet man den kopierten Schlüssel (File => Load private key), eventuell muss man den Dateityp auf "Alle Dateien" stellen, da ansonsten nur ppk-Dateien angezeigt werden. Vor dem Laden des Schlüssels muss man noch die Passphrase eingeben. Wenn alles stimmt, sollte es ungefähr so aussehen:

Putty Key Generator Jetzt kann man den Schlüssel speichern, in dem man auf den Button "save private key" (rechts unten) drückt und im daraufhin erscheinenden Menü einen Speicherplatz und einen sinnvollen Namen auswählt.



Dieser Schlüssel muss nun putty mitgeteilt werden. Dazu öffnet man putty und legt eine neue Verbindung an (also IP-Adresse oder Hostname, ssh als Protokoll etc.). Imssh-Schlüssel in Putty Unterpunkt SSH/Auth (siehe nächstes Bild) kann man nun den Pfad zum gerade gespeicherten Schlüssel angeben.



Und dann kann auch schon getestet werden, ob der Verbindungsaufbau klappt. Wenn alles im grünen Bereich ist, muss man auf der Linux-Box noch den alten Schlüssel aus der "authorized_keys" löschen. Der einfachste Weg geht wie folgt (sollte man aber nur tun, wenn dort wirklich nur ein Schlüssel drin steht):

//NSLU2~/.ssh# cp id_rsa.pub authorized_keys  

Bevor man die bestehende ssh-Verbindung schließt, erst nochmal testen, ob die neue auch wirklich, wirklich funktioniert! Ansonsten kann man sich bei der Slug nämlich schnell den letzten Weg ins System verbauen - und das wäre schlecht :-)

blog comments powered by Disqus

Design von Dicas Blogger, angepasst durch Mario Ruprecht