WardtermSSH-Client
DE
Herunterladen

"kex_exchange_identification: read: Connection reset by peer"

Die TCP-Verbindung wurde geöffnet, aber etwas hat sie vor der SSH-Begrüßung beendet. Das geschieht also, bevor irgendein Schlüssel oder Passwort geprüft wird. Meist weist der Server Sie absichtlich ab: sshd-Penalties nach fehlgeschlagenen Anmeldungen, zu viele nicht authentifizierte Verbindungen (MaxStartups) oder /etc/hosts.deny. Eine Firewall oder ein defekter Tunnel dazwischen kann dasselbe bewirken. Führen Sie ssh -v aus und lesen Sie im Log des Servers die passende Zeile.

Strafen entstehen oft durch Anmeldungen, die immer wieder scheitern. Mit Wardterm bekommt jeder Server stets die für ihn gespeicherte Anmeldung. Zeigen

Aktualisiert am . Die Fälle Penalty, MaxStartups, hosts.deny und Firewall-Reset wurden auf Debian 13 mit OpenSSH 10.0 auf beiden Seiten nachgestellt.

Die Formen dieser Meldung

kex_exchange_identification: read: Connection reset by peer
Connection reset by 203.0.113.10 port 22
kex_exchange_identification: Connection closed by remote host
Connection closed by 203.0.113.10 port 22

Aktuelle Clients geben ohne -v unter Umständen nur die letzte Zeile aus, Connection closed by 203.0.113.10 port 22. Reset und closed unterscheiden sich nur darin, wie die Verbindung endete. Behandeln Sie beides als dasselbe Problem, denn dieselbe Ursache kann je nach dem, was dazwischen sitzt, beides zeigen.

Hier anfangen

ssh -v user@server true

Diese Zeile in der Ausgabe ist ein sehr nützlicher Hinweis:

debug1: kex_exchange_identification: banner line 0: Not allowed at this time

Dieser Text kommt von sshd selbst. Er heißt, dass der Server läuft und Sie absichtlich abweist, gehen Sie also zu Ursache 1 und Ursache 2. Um den Grund zu lesen, nutzen Sie eine Konsole oder eine andere Verbindung zum Server:

sudo journalctl -u ssh -u sshd --since "1 hour ago" | grep -iE 'maxstartups|penalty'

Sind Sie ausgesperrt, probieren Sie es auch aus einem anderen Netz, etwa über einen Handy-Hotspot. Funktioniert das, ist die Sperre an Ihre Adresse gebunden.

Ursache 1: sshd-Penalties

Seit OpenSSH 9.8 bestraft sshd Adressen, deren Anmeldung fehlschlägt, und das ist standardmäßig aktiv. Solange die Penalty dauert, werden neue Verbindungen von dieser Adresse verworfen. Das Server-Log zeigt:

drop connection #0 from [203.0.113.10]:41056 on [203.0.113.20]:22 penalty: failed authentication

Warten genügt: Das Standardmaximum beträgt 10 Minuten. Es trifft Sie eher hinter einer gemeinsamen Büroadresse oder mit einem Skript oder Monitoring-Job, der dauernd fehlschlägt, beheben Sie also zuerst, was fehlschlägt. Für eine vertrauenswürdige Adresse fügen Sie dies in die sshd_config ein:

PerSourcePenaltyExemptList 203.0.113.10

Ein Client, der viele Schlüssel anbietet, kann bei einer einzigen Anmeldung mehrmals scheitern. Unter Too many authentication failures sehen Sie, wie Sie ihn auf den richtigen Schlüssel beschränken.

Ursache 2: MaxStartups

MaxStartups begrenzt Verbindungen, die noch nicht angemeldet sind. Der Standard ist 10:30:100: Ab 10 solchen Verbindungen verwirft sshd neue zufällig mit 30 % Wahrscheinlichkeit, steigend, bis bei 100 alle verworfen werden. Bots, die einen öffentlichen Server scannen, können das füllen. Das Log zeigt:

drop connection #1 from [203.0.113.10]:37954 on [203.0.113.20]:22 Maxstartups

Ältere Versionen protokollieren exceeded MaxStartups. Prüfen Sie die Einstellung und die aktuellen Verbindungen:

sudo sshd -T | grep -iE '^(maxstartups|persourcemaxstartups|logingracetime)'
ss -tn state established '( sport = :22 )'

Der Fehler tritt oft zeitweise auf: Ein neuer Versuch funktioniert. Um Platz zu schaffen, erhöhen Sie das Limit und verringern den Bot-Verkehr mit einer Firewall-Allowlist oder einer kürzeren LoginGraceTime:

MaxStartups 30:30:100

Prüfen und wenden Sie es an. Der Dienst heißt unter Debian und Ubuntu ssh und auf Red-Hat-artigen Systemen sshd:

sudo sshd -t && sudo systemctl reload ssh

Ursache 3: TCP-Wrapper

Das ursprüngliche OpenSSH hat diese Funktion längst aufgegeben, aber manche Distributionen bauen sie weiter ein. Debian 13 tut das, und eine Zeile sshd: ALL in /etc/hosts.deny erzeugte in unserem Test die Reset-Meldung. Seit OpenSSH 9.8 ist die Bibliothek an sshd-session gebunden, nicht an sshd, prüfen Sie also beide:

ldd /usr/sbin/sshd /usr/lib/openssh/sshd-session 2>/dev/null | grep libwrap
grep -v '^#' /etc/hosts.deny /etc/hosts.allow

Entfernen Sie die Regel oder erlauben Sie Ihre Adresse in /etc/hosts.allow:

sshd: 203.0.113.10

Ursache 4: eine Firewall oder fail2ban

Eine Firewall, ein Load Balancer oder ein Intrusion-Prevention-Gerät, das nach dem Öffnen der Verbindung einen TCP-Reset sendet, ergibt diese Familie von Meldungen. Wir haben es mit dieser Regel nachgestellt, wobei SSH Connection reset by peer ausgab:

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate ESTABLISHED -j REJECT --reject-with tcp-reset

fail2ban ist eine unwahrscheinlichere Ursache dieser Meldung, als viele annehmen. Seine Standardaktionen weisen neue Verbindungen ab, was der Client als Connection refused meldet, nicht als Reset. Ein Blick lohnt sich trotzdem, wenn Sie mehrere Anmeldungen verfehlt haben:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 203.0.113.10

Mehr dazu unter fail2ban für SSH.

Ursache 5: ein Tunnel mit Sackgasse

Wenn Sie sich über einen Tunnel oder eine Portweiterleitung verbinden, nimmt der erste Hop Ihre Verbindung an und erreicht dann das eigentliche Ziel nicht. Der Client sieht den Reset. Bei ssh -L zeigt das Terminal, in dem der Tunnel läuft, den wahren Grund:

channel 3: open failed: connect failed: Connection refused

Schauen Sie dort nach oder ins Log Ihres Proxys. Prüfen Sie, dass Zieladresse und Port stimmen und dass sshd auf dem Ziel läuft.

Ursache 6: sshd selbst hat ein Problem

Passt keiner der obigen Fälle, testen Sie die Konfiguration und starten Sie eine Debug-Kopie auf einem freien Port. Ihr normaler Dienst läuft weiter:

sudo sshd -t
sudo /usr/sbin/sshd -d -p 2200

Verbinden Sie sich dann mit ssh -p 2200 user@server und lesen Sie, was die Debug-Kopie ausgibt. Erlauben Sie diesen Port zuerst in Ihrer Firewall und schließen Sie ihn danach wieder.

Fragen

Was bedeutet kex_exchange_identification: Connection reset by peer?

Die TCP-Verbindung wurde geöffnet, aber vor der SSH-Begrüßung getrennt. Der Server oder etwas dazwischen hat Sie abgewiesen, bevor ein Schlüssel oder Passwort geprüft wurde.

Wie lange dauert eine Strafe von sshd?

Seit OpenSSH 9.8 wachsen die Strafen mit wiederholten Fehlschlägen, standardmäßig bis zu 10 Minuten. Warten genügt, und PerSourcePenaltyExemptList nimmt vertrauenswürdige Adressen aus.

Warum tritt der Abbruch nur manchmal auf?

Ein gelegentlicher Abbruch deutet oft auf MaxStartups: Sind zu viele Verbindungen noch bei der Anmeldung, verwirft sshd neue nach dem Zufallsprinzip.

Quellen

Mehr zu Fehlermeldungen

Alle Anleitungen