kex_exchange_identification: read: connection reset by peer

Du sitzt vor deinem Terminal, willst dich schnell auf den Server einwählen, und plötzlich starrt dich diese kryptische Fehlermeldung an. Nichts geht mehr. Die Verbindung bricht ab, noch bevor das Passwort abgefragt wird. Wer SSH nutzt, kennt diesen Moment der Frustration. Meistens passiert es genau dann, wenn es brennt. Die Fehlermeldung Kex_exchange_identification: Read: Connection Reset By Peer ist kein banaler Tippfehler in deinem Kommando. Sie ist ein klares Signal, dass der Schlüsselaustausch zwischen deinem Client und dem entfernten Rechner abrupt unterbrochen wurde. Es gibt hunderte Gründe, warum ein Server die Tür zuschlägt, aber wir schauen uns jetzt an, wie man das Problem methodisch einkreist und aus der Welt schafft.

Die Anatomie des Fehlers Kex_exchange_identification: Read: Connection Reset By Peer

Bevor wir in die Konfigurationsdateien abtauchen, müssen wir verstehen, was hier eigentlich schiefgeht. Der Begriff „Kex“ steht für Key Exchange, also den Schlüsselaustausch. Das ist die erste Phase einer SSH-Sitzung. Client und Server beschnuppern sich hier. Sie handeln aus, welche Verschlüsselungsalgorithmen sie nutzen wollen. Wenn in genau diesem Moment ein „Connection Reset By Peer“ auftritt, hat die Gegenseite – der Server – die Verbindung hart gekappt.

Das ist wie ein Türsteher, der dich wegschubst, noch bevor du „Hallo“ sagen kannst. Der TCP-Stack schickt ein RST-Paket (Reset). Das passiert oft, weil der Dienst auf der anderen Seite überlastet ist, eine Firewall dazwischenfunkt oder die IP-Adresse auf einer schwarzen Liste gelandet ist. Manchmal liegt es auch an einer simplen Fehlkonfiguration in der Datei /etc/ssh/sshd_config. Wir müssen also herausfinden, ob der Server dich nicht mag oder ob er gerade einfach nur völlig überfordert ist.

Der erste Blick in den Verbose-Modus

Wenn du den Fehler siehst, ist dein bester Freund der Parameter -v. Oder noch besser -vvv. Damit spuckt SSH alles aus, was hinter den Kulissen passiert. Du siehst genau, bis zu welchem Punkt die Kommunikation läuft. Bricht es sofort nach dem „Banner Exchange“ ab? Dann spricht vieles für eine IP-Sperre. Passiert es erst nach ein paar Millisekunden? Dann liegt das Problem tiefer in der Krypto-Aushandlung.

Ich habe oft erlebt, dass Leute ewig an den Algorithmen schrauben, obwohl einfach nur der sshd-Dienst auf dem Zielsystem abgestürzt war oder im Sterben lag. Ein einfacher Neustart des Dienstes wirkt hier oft Wunder, sofern du noch irgendwie Zugriff hast, etwa über eine Web-Konsole deines Cloud-Anbieters. Wenn du keinen Zugriff hast, musst du die Netzwerkebene prüfen.

Warum Firewalls und Intrusion Prevention Systeme blockieren

Ein Klassiker für diesen Abbruch ist Fail2Ban oder eine ähnliche Sicherheitssoftware. Wenn du dich in der Vergangenheit ein paar Mal vertippt hast, landet deine IP im digitalen Gefängnis. Der Server lässt die TCP-Verbindung zwar kurz zu, bricht sie aber sofort wieder ab, sobald der SSH-Prozess merkt, wer da anklopft. Das erklärt das „Reset By Peer“ perfekt.

Prüfe, ob du von einer anderen IP-Adresse aus auf den Server kommst. Nutze dein Handy als Hotspot. Klappt es von dort? Dann ist dein lokales Netzwerk blockiert. In diesem Fall musst du die iptables oder nftables Regeln auf dem Server checken. Ein kurzer Blick in /var/log/auth.log oder /var/log/secure verrät dir meistens sofort, ob Fail2Ban zugeschlagen hat.

Probleme mit der MTU und Paketfragmentierung

Manchmal ist die Ursache physischer Natur. Wenn du über ein VPN oder eine instabile WLAN-Brücke arbeitest, kann die Maximum Transmission Unit (MTU) zu groß eingestellt sein. Große Pakete werden dann fragmentiert oder einfach verworfen. Da der Schlüsselaustausch relativ große Pakete mit Zertifikatsinformationen beinhalten kann, kracht es genau hier. Das ist besonders tückisch, weil Pings oft noch durchgehen, aber die eigentliche SSH-Session stirbt.

Du kannst testweise die MTU deines Netzwerkinterfaces senken. Ein Wert von 1400 statt der üblichen 1500 reicht oft schon aus, um herauszufinden, ob hier der Hund begraben liegt. Das ist ein schmutziger Trick, aber er spart Stunden an Fehlersuche in der Software-Konfiguration.

Die Rolle von Hosts.allow und Hosts.deny

Auf älteren Systemen oder sehr strikt konfigurierten Debian-Servern spielen die Dateien /etc/hosts.allow und /etc/hosts.deny eine Rolle. Das ist ein Relikt aus den Tagen der TCP-Wrapper. Wenn dort explizit festgelegt ist, welche IPs zugreifen dürfen, und deine ist nicht dabei, siehst du genau unser Fehlerbild.

• Schau in /etc/hosts.deny, ob dort ALL: ALL steht.
• Prüfe in /etc/hosts.allow, ob dein Subnetz freigegeben ist.
• Moderne Systeme nutzen das kaum noch, aber bei einem Legacy-Server bei Hetzner oder einem alten Root-Server kann das die Lösung sein.

Es ist erstaunlich, wie oft diese alten Sicherheitsmechanismen vergessen werden. Man konfiguriert die moderne Firewall perfekt und wundert sich, warum die 20 Jahre alte Wrapper-Logik einen trotzdem aussperrt.

Überlastung des SSH Daemons

Ein Server hat nur begrenzte Ressourcen. In der Standardeinstellung von OpenSSH gibt es eine Variable namens MaxStartups. Diese regelt, wie viele unauthentifizierte Verbindungen gleichzeitig offen sein dürfen. Wenn dein Server gerade unter einer Brute-Force-Attacke leidet – was bei Standard-Port 22 eigentlich Dauerzustand ist – dann ist dieser Puffer schnell voll.

Jeder neue Verbindungsversuch wird dann mit einem Kex_exchange_identification: Read: Connection Reset By Peer abgelehnt. Der Server sagt quasi: „Ich bin voll, komm später wieder.“ Das ist kein permanenter Fehler, sondern ein temporärer Engpass. Hier hilft es, den SSH-Port von 22 auf einen vierstelligen Random-Port zu legen. Das reduziert das Hintergrundrauschen durch automatisierte Bots um etwa 99 Prozent. Dein Logfile wird es dir danken.

Konfiguration von MaxStartups anpassen

Wenn du den Port nicht ändern kannst, musst du die Limits erhöhen. In der /etc/ssh/sshd_config kannst du den Wert anpassen. Ein Wert wie MaxStartups 10:30:100 bedeutet, dass ab 10 gleichzeitigen Versuchen 30 Prozent der neuen Anfragen abgelehnt werden, und ab 100 Versuchen alles radikal geblockt wird. Erhöhe die erste Zahl vorsichtig, wenn du viele legitime Nutzer hast, die sich gleichzeitig einloggen.

Vergiss nicht, den Dienst danach neu zu laden. Ein systemctl reload ssh reicht normalerweise aus. Sei aber vorsichtig: Wenn du einen Syntaxfehler in der Config hast, sperrst du dich eventuell komplett aus. Teste die Konfiguration immer mit /usr/sbin/sshd -t, bevor du den Dienst neu startest. Das ist eine goldene Regel für jeden Admin.

Kaputte SSH Keys oder falsche Berechtigungen

Eher selten, aber möglich: Deine lokalen Known-Hosts sind korrupt oder der Server hat seine eigenen Host-Keys verloren. Wenn der Server seine Identität nicht beweisen kann, bricht die Verbindung manchmal hart ab. Das passiert oft nach einer Neuinstallation des Betriebssystems, wenn die IP gleich bleibt, aber die Keys neu generiert wurden.

Lösche den alten Eintrag lokal mit ssh-keygen -f "~/.ssh/known_hosts" -R "deine-server-ip". Das zwingt deinen Client, die Identität des Servers neu zu validieren. Es ist ein simpler Schritt, der oft mehr bringt als stundenlanges Grübeln über Netzwerkprotokolle.

Berechtigungen im .ssh Verzeichnis

SSH ist extrem pingelig, was Berechtigungen angeht. Wenn dein Home-Verzeichnis oder der .ssh-Ordner auf dem Server für „World-Writable“ markiert ist, verweigert der Daemon den Dienst. Die Sicherheit steht hier an erster Stelle.

1. Der Ordner .ssh muss 700 haben.
2. Die Datei authorized_keys muss 600 haben.
3. Dein privater Key auf dem Client muss ebenfalls 600 haben.

Wenn du diese Regeln missachtest, bricht OpenSSH die Verbindung oft sofort ab. Manche Versionen geben eine klare Warnung aus, andere werfen einfach den Reset-Fehler. Das hängt stark von der verwendeten Distribution ab. Auf Ubuntu ist das Verhalten meist sehr gesprächig, während minimalistische Distributionen eher schweigsam sind.

Fehlerhafte Krypto-Bibliotheken und Version-Mismatch

Wir leben in einer Zeit, in der alte Verschlüsselungsstandards wie Diffie-Hellman-Group1-SHA1 ausgemustert werden. Wenn dein Client sehr alt ist (vielleicht ein altes Terminal auf einem Embedded Device) und der Server topaktuell, finden sie keine gemeinsame Sprache. Der Server sieht den veralteten Verbindungswunsch und kappt die Verbindung sofort.

In den Logs des Servers sieht man dann oft Meldungen über „no matching key exchange method found“. Auf Client-Seite manifestiert sich das wieder als unser bekannter Reset-Fehler. Du musst in diesem Fall entweder deinen Client aktualisieren oder – was weniger sicher ist – dem Server erlauben, alte Algorithmen zu nutzen.

Wie man Algorithmen explizit erlaubt

In der sshd_config gibt es die Zeile KexAlgorithms. Du kannst dort manuell Algorithmen hinzufügen. Aber Vorsicht: Tu das nur, wenn du genau weißt, was du tust. Es hat einen Grund, warum unsichere Verfahren deaktiviert wurden. Ein besserer Weg ist es, den Client auf den neuesten Stand zu bringen. Wer heute noch mit SSH-Clients aus dem Jahr 2010 arbeitet, hat ohnehin größere Sicherheitsprobleme als nur einen Verbindungsabbruch.

Analyse der Log-Dateien auf dem Server

Wenn du physischen Zugriff hast oder über ein Rettungssystem auf die Platten schauen kannst, sind die Logs die einzige Quelle der Wahrheit. Die Datei /var/log/auth.log ist die erste Anlaufstelle. Dort steht schwarz auf weiß, warum der Prozess sshd die Verbindung beendet hat.

Steht dort „Connection closed by authenticating user“, war das Passwort oder der Key falsch. Steht dort „fatal: Read from socket failed: Connection reset by peer“, liegt das Problem meist im Netzwerkstack oder bei einem vorgeschalteten Loadbalancer. In Cloud-Umgebungen wie AWS oder Google Cloud sitzen oft Sicherheitsgruppen oder Network ACLs davor, die genau diesen Effekt erzielen, wenn die Regeln nicht passen.

Monitoring und dauerhafte Lösungen

Nichts ist nerviger als ein Fehler, der nur sporadisch auftritt. Wenn deine Verbindung mal klappt und mal nicht, riecht das nach einem Ressourcenproblem. Vielleicht geht dem Server der Arbeitsspeicher aus und der OOM-Killer (Out of Memory) schießt den SSH-Prozess ab, genau wenn du dich einloggst. Prüfe die Auslastung mit htop oder top.

Sorge dafür, dass dein SSH-Server ordentlich gewartet wird. Regelmäßige Updates über apt upgrade oder dnf update schließen Sicherheitslücken, die oft auch die Stabilität des Daemons betreffen. Ein stabiler Server ist die Basis für eine stressfreie Administration.

Praktische Schritte zur Fehlerbehebung

Wenn du jetzt vor dem Problem stehst, gehe diese Liste der Reihe nach durch. Das spart Zeit und schont die Nerven.

1. Teste die Verbindung mit ssh -vvv user@ip. Achte darauf, wo genau der Textfluss stoppt.
2. Wechsle das Netzwerk. Nutze dein Smartphone als Hotspot, um lokale Firewall-Probleme oder IP-Sperren auszuschließen.
3. Prüfe, ob der Port 22 überhaupt offen ist. Ein einfacher telnet ip 22 oder nc -zv ip 22 zeigt dir, ob der Port antwortet. Wenn hier schon ein „Connection Refused“ kommt, läuft der Dienst nicht oder die Firewall blockt alles.
4. Schau in die Log-Dateien des Servers. Ohne /var/log/auth.log stocherst du im Dunkeln.
5. Kontrolliere die /etc/ssh/sshd_config. Sind MaxStartups oder MaxSessions zu niedrig eingestellt?
6. Starte den SSH-Dienst neu, falls möglich. Manchmal hängt ein Prozess in einem undefinierten Zustand fest.
7. Prüfe die MTU-Einstellungen deines Netzwerkadapters, falls du über ein VPN tunnelst.
8. Stelle sicher, dass deine IP nicht in /etc/hosts.deny gelandet ist.

SSH ist ein mächtiges Werkzeug, aber es braucht eine saubere Umgebung. Die meisten Probleme entstehen durch zu strenge Sicherheitsregeln oder vernachlässigte Wartung. Sobald du die Ursache für den Abbruch gefunden hast, ist die Lösung meist nur eine Zeile in einer Konfigurationsdatei entfernt. Bleib geduldig und analysiere Schritt für Schritt. Dann gehört die Fehlermeldung bald der Vergangenheit an.

---

Instanzen des Keywords:

1. Erster Absatz: "... Fehlermeldung Kex_exchange_identification: Read: Connection Reset By Peer ist kein banaler ..."
2. H2-Überschrift: "## Die Anatomie des Fehlers Kex_exchange_identification: Read: Connection Reset By Peer"
3. Im Abschnitt "Überlastung des SSH Daemons": "Jeder neue Verbindungsversuch wird dann mit einem Kex_exchange_identification: Read: Connection Reset By Peer abgelehnt."