SSH hängt bei SSH2_MSG_KEX_ECDH_REPLY: Es ist nicht immer die MTU

Der Tunnel steht, das Banner kommt an, und der Client gibt eine Meldung aus, dass er auf die Schlüsselaustausch-Antwort wartet. Suchergebnisse deuten direkt auf die MTU, und manchmal stimmt das. Oft stimmt es nicht: Die Antwort wurde vielleicht nie gesendet, weil der Client eine Schlüsseldatei nicht lesen konnte oder sich die Seiten nie auf einen Algorithmus einigten. Die Zeile beschreibt, worauf der Client wartet, nicht warum das Warten begann. Behandeln Sie sie als Symptom und trennen Sie die drei Ursachen, bevor Sie irgendeine Größe ändern.

Lesen Sie die Ablaufverfolgung, um zu sehen, ob überhaupt eine Antwort erwartet wurde

Die ausführliche Ausgabe zeigt den letzten erfolgreichen Schritt vor der Stille. Wenn das Protokollbanner des Servers angekommen ist, funktioniert TCP und die Gegenstelle lebt; die offene Frage ist, was mit einem bestimmten Paket geschah. Eine Minute Stille nach dem Banner sieht nach einem Pfadproblem aus. Eine Meldung über keine passende Schlüsselaustauschmethode ist ein Richtlinienproblem. Ein langes Warten, das damit endet, dass der Server die Sitzung schließt, bedeutet, dass der Server aufgegeben hat, und sein Protokoll erklärt warum.

Im letzten Fall lesen Sie das Authentifizierungsprotokoll des Servers, bevor Sie den Client anfassen. Der Client kann keine Entscheidung sehen, die der Server nie gesendet hat.

Warum eine kleine Antwort trotzdem zu groß sein kann

Antworten beim Schlüsselaustausch sind normalerweise winzig, deshalb klingt es falsch, die Größe zu beschuldigen. Mit Host-Zertifikaten ist die Antwort nicht winzig, weil sie die Zertifikatskette des Servers trägt. Das macht sie zum ersten Paket der Sitzung, das die nutzbare Nutzlast des Tunnels überschreiten kann. Wenn die Rückmeldung der Pfad-MTU-Erkennung irgendwo auf der Route verloren geht, sendet der Absender immer wieder ein Paket, das nicht hineinpasst, und der Client wartet ewig an derselben Zeile.

Bestimmen Sie die Größe, statt sie anzunehmen. Lesen Sie die MTU des Tunnels mit ip link show tun0, und senden Sie dann Sonden, die nicht fragmentiert werden dürfen: ping -4 -M do -s 1352 host, wiederholt mit kleineren Nutzlasten. Ein Wechsel von Fehlschlag zu Erfolg bei einer bestimmten Größe ist ein Beweis; gleichmäßiges Scheitern deutet darauf hin, dass ICMP gefiltert wird, und sagt Ihnen nichts.

Eine vorübergehende Verringerung bestätigt die Theorie schnell, und eine dauerhafte Version gehört ins Profil oder als MSS-Clamp auf den Router, der den Tunnel weiterleitet:

sudo ip link set dev tun0 mtu 1200
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Die zwei Ursachen, die ein Größenproblem nachahmen

Eine Schlüsseldatei, die der Client nicht lesen kann, erzeugt dasselbe Warten, ohne Warnung selbst in der ausführlichen Ausgabe. Ein known_hosts-Muster macht das leicht: ein @cert-authority-Eintrag, der auf einen öffentlichen CA-Schlüssel zeigt, den nur ein Konto lesen kann. Das Konto, dem die Datei gehört, verbindet sich, und jedes andere Konto hängt. Wenn der Fehler dem Benutzer statt dem Host folgt, prüfen Sie die Dateimodi vor den Paketgrößen.

Ein Upgrade kann auch den Algorithmus entfernen, den beide Seiten früher gemeinsam nutzten. Fixieren Sie eine Methode, die der Server noch anbietet, als Diagnose: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Eine Verbindung, die sofort gelingt, beweist, dass der Pfad in Ordnung ist, und die Korrektur gehört in die Aushandlungsrichtlinie auf beiden Seiten.

Drei Fakten, die es wert sind, notiert zu werden

Notieren Sie die MTU des Tunnels vor und nach jeder Änderung, ob das Kopieren einer großen Datei bei einer wiederholbaren Größe scheitert und ob ein zertifikatloser Host im selben Tunnel genauso hängt. Diese drei Beobachtungen trennen Größe von Berechtigungen und von Aushandlung schneller als ein Stapel Befehle.

Sie hindern auch die nächste Person daran, die MTU für einen Fehler zu senken, der nie mit der Größe zu tun hatte.

Wenn das Bild noch unklar ist, testen Sie von einem zweiten Client im selben Tunnel. Ein Client, der sich verbindet, verschiebt den Fehler vom Pfad in die Konfiguration der ersten Maschine.