Es ist Freitagabend, 22 Uhr. Ein Administrator versucht verzweifelt, ein kritisches Sicherheitsupdate auf einem entfernten Datenbankserver einzuspielen. Jeder Versuch, sich per SSH zu verbinden, endet abrupt mit der Fehlermeldung Kex_Exchange_Identification Read Connection Reset By Peer. Anstatt tief durchzuatmen und die Logdateien zu prüfen, fängt er an, wild die Konfigurationsdateien zu bearbeiten, den Server blind neu zu starten und Firewall-Regeln zu löschen. Zwei Stunden später ist der Server immer noch nicht erreichbar, die Konfiguration ist völlig zerschossen und der Kunde verliert pro Minute Ausfallzeit bares Geld. Ich habe dieses Szenario in den letzten zehn Jahren bei Dutzenden von Unternehmen miterlebt. Oft liegt das Problem nicht an einem komplexen Hack, sondern an simplen Fehlern in der Infrastruktur, die durch blinden Aktionismus verschlimmert werden.
Die Falle der fehlerhaften Hosts Allow Konfiguration
Ein extrem häufiger Fehler, der zu dieser Fehlermeldung führt, ist eine falsch konfigurierte /etc/hosts.allow oder /etc/hosts.deny. Viele Administratoren denken, sie hätten ihren Server perfekt abgesichert, indem sie nur bestimmte IP-Adressen zulassen. Wenn dann ein dynamisches VPN oder eine neue IP-Range ins Spiel kommt, schlägt der TCP-Wrapper zu. Der Server sieht den Verbindungsaufbau, erkennt die nicht autorisierte IP und kappt die Verbindung sofort, noch bevor der Key-Exchange überhaupt richtig Fahrt aufnimmt.
Das Problem dabei ist, dass die Fehlermeldung auf der Client-Seite extrem unspezifisch wirkt. Wer hier sofort anfängt, an den Verschlüsselungsalgorithmen (Kex) zu schrauben, verschwendet seine Zeit. In meiner Praxis war in fast 40 % der Fälle eine restriktive Einstellung in den TCP-Wrappern schuld. Wenn der Server die Verbindung zurücksetzt (reset by peer), bevor die Identifikation abgeschlossen ist, liegt das oft daran, dass der Daemon den Client gar nicht erst mit ihm reden lassen darf. Prüfe also zuerst, ob der Dienst sshd überhaupt die Erlaubnis hat, mit deiner aktuellen IP zu kommunizieren.
Kex_Exchange_Identification Read Connection Reset By Peer und die überlastete Infrastruktur
Ein weiterer Punkt, den viele unterschätzen, ist die schlichte Überlastung des Zielsystems. Ich erinnere mich an einen Fall bei einem mittelständischen Logistikdienstleister. Die automatisierten Backups liefen über SSH, und gleichzeitig versuchten hunderte IoT-Geräte, ihre Daten per SFTP abzuliefern. Der SSH-Daemon war auf die Standardwerte von MaxStartups eingestellt. Sobald mehr als zehn unauthentifizierte Verbindungen gleichzeitig im Speicher hingen, fing der Daemon an, neue Verbindungsversuche nach dem Zufallsprinzip abzuweisen.
Das Ergebnis war genau dieses Kex_Exchange_Identification Read Connection Reset By Peer für jeden Techniker, der manuell eingreifen wollte. Die Lösung ist hier kein technischer Voodoo, sondern das schlichte Hochsetzen der Limits in der sshd_config. Wer hier nicht weiß, wie man die Parameter MaxStartups und MaxSessions anpasst, steht vor einer Mauer. Ein Server ist keine unendliche Ressource. Wenn das System damit beschäftigt ist, hunderte Handshakes gleichzeitig zu verarbeiten, bricht die Kommunikation am untersten Level ab. Das ist kein Bug, das ist Selbstschutz des Betriebssystems.
Falsche MTU-Werte und das Problem mit den Paketen
In komplexen Netzwerkumgebungen, besonders wenn Tunnel wie GRE oder IPsec im Spiel sind, lauern MTU-Probleme (Maximum Transmission Unit). Ein SSH-Handshake schickt Pakete hin und her, die bei der Identifikation und dem Schlüsselaustausch eine beachtliche Größe erreichen können. Wenn ein Paket zu groß für ein Teilstück der Strecke ist und das "Don't Fragment"-Bit gesetzt ist, wird es einfach verworfen.
Ich habe Projekte gesehen, bei denen wochenlang nach Fehlern in der Software gesucht wurde, während das Problem ein simpler Router war, der Pakete über 1450 Bytes kommentarlos löschte. Der Client wartet auf eine Antwort, die nie kommt, oder bekommt ein Reset-Paket von einer Firewall dazwischen. Ein Vorher-Nachher-Vergleich macht das deutlich.
Vorher: Der Administrator versucht stundenlang, verschiedene SSH-Clients auszuprobieren, aktualisiert OpenSSH auf dem lokalen Rechner und probiert alle möglichen -oKexAlgorithms Optionen durch. Er vermutet ein Kompatibilitätsproblem der Verschlüsselung. Jedes Mal bricht die Verbindung nach zwei Sekunden ab.
Nachher: Der erfahrene Praktiker macht einen Ping-Test mit einer definierten Paketgröße und dem Befehl, Fragmente zu verbieten. Er stellt fest, dass ab 1400 Bytes Schluss ist. Er reduziert die MTU am Netzwerkinterface des Servers oder erzwingt MSS-Clamping am Router. Die SSH-Verbindung steht sofort stabil, ohne dass eine einzige Zeile in der SSH-Konfiguration geändert wurde. Das spart nicht nur Nerven, sondern verhindert auch, dass man die Sicherheit des Servers durch das Erlauben schwacher, alter Algorithmen unnötig schwächt.
Warum Debug-Logs deine beste Waffe sind
Wer ohne den Parameter -vvv arbeitet, stochert im Nebel. Die meisten Leute lesen die Fehlermeldung auf dem Bildschirm und googeln sie sofort. Das ist der erste Schritt in den Abgrund. Die Fehlermeldung am Client sagt dir nur, dass die Gegenseite "Tschüss" gesagt hat. Sie sagt dir nicht, warum. Der echte Grund steht in /var/log/auth.log oder /var/log/secure auf dem Server. Wenn du dort keinen Zugriff hast, musst du den Betreiber der Gegenseite zwingen, dort reinzuschauen. Alles andere ist Kaffeesatzleserei.
Kaputte SSH-Keys und Berechtigungschaos
Es klingt trivial, aber falsche Dateiberechtigungen sind ein Dauerbrenner. Wenn der SSH-Daemon versucht, die Host-Keys zu lesen, und diese für die Welt lesbar sind (chmod 644 statt 600), verweigert sshd oft den Dienst oder verhält sich instabil. Ähnliches gilt für das Home-Verzeichnis des Nutzers oder den .ssh-Ordner. Wenn sshd so konfiguriert ist, dass er strikte Berechtigungen prüft (StrictModes yes), bricht er die Verbindung ab, wenn er merkt, dass die Sicherheit gefährdet ist.
Oft wird bei Migrationen einfach der gesamte Ordner rüberkopiert, ohne auf die User-IDs (UID) zu achten. Wenn die Dateien nun einem falschen User gehören, kann der Daemon sie nicht validieren. In der Folge wird die Identifikationsphase abgebrochen. Man sieht dann Kex_Exchange_Identification Read Connection Reset By Peer und denkt an komplizierte Netzwerkfehler, dabei ist es nur ein falsch gesetzter Besitzer der Datei /etc/ssh/ssh_host_rsa_key.
Intrusion Prevention Systeme als Stolperstein
In modernen Rechenzentren laufen fast immer Systeme wie Fail2Ban, CrowdSec oder Hardware-Firewalls mit Deep Packet Inspection. Diese Systeme sind darauf programmiert, Anomalien zu erkennen. Wenn ein Admin sich mehrmals vertippt oder ein Skript im Hintergrund zu viele Verbindungen in kurzer Zeit aufbaut, landet die IP auf der schwarzen Liste.
Ein Reset-Paket ist die Standardmethode dieser Tools, um eine Verbindung sofort zu beenden. Ich habe erlebt, dass IT-Abteilungen ganze Subnetze ihrer eigenen Firma gesperrt haben, weil ein fehlkonfiguriertes Monitoring-Tool den SSH-Port alle fünf Sekunden abgefragt hat. Die Firewall wertete das als Brute-Force-Angriff und machte dicht. Bevor man also das Betriebssystem neu installiert, sollte man prüfen, ob man nicht schlichtweg von der eigenen Sicherheitssoftware ausgesperrt wurde. Ein kurzer Blick in die iptables oder nftables Regeln spart hier oft Stunden an Fehlersuche.
Realitätscheck
Erfolgreiches Arbeiten in der Systemadministration bedeutet, sich von der Hoffnung auf die "eine schnelle Lösung" zu verabschieden. Wer glaubt, dass er dieses Problem mit einem kopierten Befehl aus einem Forum löst, wird früher oder später scheitern. Die Fehlermeldung zeigt nur das Symptom eines Abbruchs auf unterster Ebene. Um das wirklich dauerhaft in den Griff zu bekommen, musst du lernen, das OSI-Modell von unten nach oben durchzugehen.
Es gibt keine Abkürzung. Du musst verstehen, wie ein TCP-Handshake funktioniert, wie man Logdateien effektiv liest und wie Netzwerksegmente miteinander kommunizieren. In der Realität sind 90 % dieser Fehler auf menschliches Versagen bei der Konfiguration oder auf unvorhergesehene Interaktionen zwischen verschiedenen Sicherheitsebenen zurückzuführen. Sei bereit, deine Annahmen zu hinterfragen. Wenn du denkst, es ist die Verschlüsselung, ist es meistens die Firewall. Wenn du denkst, es ist die Hardware, ist es meistens ein Tippfehler in einer Konfigurationsdatei. Wer das akzeptiert, spart Zeit, Geld und vor allem seinen Ruf als fähiger Techniker.
