[gelöst] ssh geht nicht mehr

[PASST]

Hallo allerseits,

ich habe ein Debian Etch mit Kernel 2.6.18-6-686. Gestern habe ich ein aptitude update + upgrade + dist-upgrade durchgeführt und seit dem kann ich mich nicht mehr über putty per ssh verbinden. Installiert ist OpenSSH 4.3p2-9etch2.

Ein Portscan auf den Rechner meldet mit den offenen Port 22

gruß
Peter

[nepos]

Zwei Möglichkeiten:
1) Putty blockt die Verbindung, weil sich durch das OpenSSH-Update der Host-key des Servers geändert hat. Da bin ich mir aber nicht 100% sicher, ob Putty das prüft.

2) Du benutzt zur Anmeldung einen Key und dieser ist aufgrund eines Bugs in OpenSSL als kompromittiert eingestuft.

Was genau meldet Putty, wenn der Login nicht klappt?

[PASST]

Die Meldung ist

Code: Alles auswählen

Network error: Software caused connection abort

[nepos]

Aktivier mal im Putty das Logging (das geht irgendwo, weiss grad aber nicht mehr, wo genau) und schau dir das mal an. Eventuell steht da mehr, warum die Verbindung zugemacht wird.
Kommst du auf den Server anderweitig drauf und kannst dir da mal ansehen, was der sshd so loggt?

[PASST]

putty logt leider erst, wenn eine Verbindung zustande kommt. Dies ist hier aber nicht der Fall und somit gibt es auch kein log.

Im syslog steht leider auch nichts. Wo logt denn sshd?

Ich habe jetzt auch von einem anderen debian system mich per ssh zu verbinden versucht. Das schlägt dann fehl mit der Meldung:

Code: Alles auswählen

admin@mail:~$ ssh -v 192.168.41.40
OpenSSH_4.7p1, OpenSSL 0.9.8e 23 Feb 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.41.40 [192.168.41.40] port 22.
debug1: Connection established.
debug1: identity file /home/admin/.ssh/identity type -1
debug1: identity file /home/admin/.ssh/id_rsa type -1
debug1: identity file /home/admin/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 Debian-9etch2
debug1: match: OpenSSH_4.3p2 Debian-9etch2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer

[debianoli]

Den Server schon mal neugestartet?
Hast du noch einen Snapshot der Situation vor dem Upgrade? Dann diese zurückspielen.

Ich hatte die gleiche Fehlermeldung nach dem Umkopieren der Root-Partiton auf einen USB-Stick für meine Nslu (Debian Etch). Davor hatte ich die Root-Partition im laufenden Betrieb (natürlich per etabliertem ssh-Login) gesichert. Dann lief zwar das System auf der Nslu vom USB-Stick, alle richtigen Ports waren offen, aber ich kam mit obiger Fehlermeldung nicht drauf. Und ein Neustart war natürlich nicht möglich - kein ssh, kein reboot...

Lösung: Umkopieren der Root-Partition an einem anderen Rechner von der abgesteckten USB-Platte auf den USB-Stick. Dann ging alles auf Anhieb.

Scheinbar speichert ssh im laufenden Betrieb irgendwo Checksummen, nur wo, weiß ich leider nicht.

[PASST]

reboot hilft auch nicht. ein backup/snapshot habe ich auch nicht, ist aber nicht nötig, da es nur ein testsystem ist.

wenn ich ssh deinstalliere, wie kriege ich denn dann die alten dazugehörenden Dateien gelöscht?

[debianoli]

reboot hilft auch nicht. ein backup/snapshot habe ich auch nicht, ist aber nicht nötig, da es nur ein testsystem ist.

wenn ich ssh deinstalliere, wie kriege ich denn dann die alten dazugehörenden Dateien gelöscht?

locate ssh und dann suchen... deinstallieren aller Pakete mit der --purge Option

[nepos]

Wenn du ssh deinstallieren kannst, dann kannst du ja auch anders als per SSH auf den Rechner.
Wie wäre es, wenn du mal schaust, wo das Problem liegt?
Der sshd auf dem Rechner loggt ja auch bisschen was.
Z.B. könntest du ihn dann auch mal mit

Code: Alles auswählen

sshd -Dd

starten, um etwas Debug-Ausgaben zu bekommen.

[PASST]

Ich habe ssh komplett gepurged, das Verzeichnis /etc/ssh/ gelöscht und danach ssh wieder neuinstalliert.
Der Fehler bleibt aber derselbe.

Wenn ich sshd -Dd starte, erhalte ich beim fehlgeschlagenen Verbindungsversuch die Meldung:

Code: Alles auswählen

Did not receive identification string from <ip-adress>

[PASST]

Das Problem ist gelöst.

Beim Starten des ssh Servers erhalte ich immer die Meldung

Code: Alles auswählen

sshd host key is blacklisted

Nachdem ich die beiden Datei /etc/ssh/blacklist.DSA-1024 (~RSA-2048) umbenannt habe, kann ich mich auch wieder verbinden.

Wie ich anfangs geschrieben habe, habe ich das System aktualisiert und dabei ist OpenSSH aktualisiert worden. Dabei ist auch das Paket openssh-blacklist angezeigt worden. Ob es jetzt neu installiert oder nur aktualisiert worden ist, kann ich nicht sagen. Hat jemand eine Idee, wie ich da vorgehen soll?

[PASST]

Ich habe genau zu diesem Problem einen Artikel bei Heise gefunden.

http://www.heise.de/security/Der-kleine ... l/108001/0

[striker2150]

Ich würde dir dazu Raten, dass Du ganz schnell das File wieder zurück umbenennst und dir neue Keys generierst.

Da gab es ein ganz gewaltiges Sicherheitsloch im Debian OpenSSL, da das Generieren von Zufallszahlen durch einen Patch fehlerhaft war und dadurch unsichere Keys generiert worden sind.

Soll heißen in der Blacklist stehen die ganzen schwachen Keys drin und es hat schon seinen Sinn und Zweck warum die in der Blacklist stehen.

[PASST]

da stimme ich dir schon zu. ich hatte das aber ignoriert, da es nur eine testksite zum spielen ist.

Wie kann ich denn einen neuen schlüssel generieren?

[nepos]

Wenn du die alten löscht, dann sollte der SSH-Daemon beim Starten automatisch welche generieren.
Wenn nicht, musst du halt mit ssh-keygen fix welche erzeugen. Das wie steht in der Man-Page.

[PASST]

Ich habe jetzt die vier key dateien aus /etc/ssh/ gelöscht, ssh-keygen ausgeführt, die beiden blacklist-dateien wieder korrekt benannt und ssh neu gestartet. Aber verbinden kann ich mich vom client nicht.

Code: Alles auswählen

ssh 192.168.41.40 -v
OpenSSH_4.7p1, OpenSSL 0.9.8e 23 Feb 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.41.40 [192.168.41.40] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 Debian-9etch2
debug1: match: OpenSSH_4.3p2 Debian-9etch2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer

Was ist da los?

[nepos]

Du debugst immer auf dem Client, obwohl deine Probleme auf dem Server liegen!!!
Also, da schauen und die Logs checken!

[PASST]

Im syslog steht nichts. Wo muss ich nachschauen?

[nepos]

Code: Alles auswählen

grep sshd /var/log/*.log

Das sagt dir, der sshd loggt normal in /var/log/auth.log. Also die mal checken.
Alternativ kannst du auch einfach mal den sshd im Debugmodus laufen lassen, wie ich schon mal gesagt habe. Dann kriegst du alle Infos direkt auf dem Terminal.

[PASST]

Ich glaube, ich habe bei der Erstellung der neuen key Dateien etwas falsch gemacht. ssh zeigt mir zwar beim Start keine Fehlermeldung wg fehlender Key Dateien an, aber beim Verbinden erhalte ich die Meldung, dass die key Dateien /etc/ssh/ssh_host_dsa_key und ..rsa_key fehlen. Sie sind auch dort tatsächlich nicht mehr vorhanden.

[PASST]

Hm, jetzt zeigt mir sshd beim Starten wieder an, dass diese beiden Key-Dateien fehlen.
Seltsam...

[nepos]

Ok, sorry, er scheint die Keys nicht automatisch anzulegen.
Dann halt manuell:

Code: Alles auswählen

ssh-keygen -t rsa -N "" -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t dsa -N "" -f /etc/ssh/ssh_host_dsa_key

Danach dann noch den sshd restarten:

Code: Alles auswählen

/etc/init.d/ssh restart

[PASST]

Danke für die Hilfe. Allerdings sagt mir ssh beim Start, dass die beiden Keys blacklisted sind.
Wat nu? Wie erzeuge ich keys, die nicht in der blacklist enthalten sind?

[nepos]

Uhm, das sollte eigentlich nicht passieren. Hast du wirklich alle Updates eingespielt?
Wenn du auf einem aktuellen System die Keys erzeugst, dann sollten die eigentlich nicht mehr in der Blacklist sein dürfen, da ja nun wieder korrekt Zufallsdaten bei der Erzeugung mit einfliessen...

[PASST]

das system sollte eigentlich aktuell sein:
aptitude update -> upgrade -> dist-upgrade