SSH hänkt bei SSH2_MSG_KEX_ECDH_REPLY: et ass net ëmmer d'MTU

Den Tunnel ass op, de Banner kënnt un, an de Client dréckt eng Noriicht aus, datt hie op d'Äntwert vum Schlësselaustausch waart. Sichresultater weisen direkt op d'MTU, an heiansdo ass dat richteg. Dacks net: d'Äntwert gouf vläicht ni geschéckt, well de Client eng Schlësselfichier net konnt liesen oder sech d'Parteien ni op en Algorithmus g'eenegt hunn. D'Linn beschreift, op wat de Client waart, net firwat d'Waarde ugefaang huet. Behandelt se als Symptom an trennt déi dräi Ursaachen, ier Dir eng Gréisst ännert.

Liest den Trace, fir ze gesinn, ob iwwerhaapt eng Äntwert erwaart gouf

Déi ausféierlech Ausgab weist de leschte erfolgreiche Schrëtt virun der Rou. Wann de Protokollbanner vum Server ukomm ass, funktionéiert TCP an déi wäit Enn ass lieweg; déi oppe Fro ass, wat mat engem bestëmmte Pak geschitt ass. Eng Minutt Rou nom Banner gesäit aus wéi e Weeproblem. Eng Noriicht iwwer keng passend Schlësselaustauschmethod ass e Politikproblem. Eng laang Waard, déi domat ophält, datt de Server d'Sessioun zoumécht, heescht de Server huet opginn, a säi Log erkläert firwat.

Am leschte Fall liest dem Server säin Authentifikatiounslog, ier Dir de Client beréiert. De Client kann eng Entscheedung net gesinn, déi de Server ni geschéckt huet.

Firwat eng kleng Äntwert trotzdem ze grouss ka sinn

Äntwerten um Schlësselaustausch si normalerweis kleng, dofir kléngt et falsch, d'Gréisst ze beschëllegergen. Mat Hostzertifikaten ass d'Äntwert net kleng, well se dem Server seng Zertifikatsketten dréit. Dat mécht se zum éischte Pak an der Sessioun, deen d'notzbar Notzlaascht vum Tunnel iwwerschreide kann. Wann d'Réckmeldung vun der Wee-MTU-Entdeckung iergendwou op der Streck verluer geet, schéckt de Sender ëmmer erëm e Pak, dat net passt, an de Client waart fir ëmmer op der selwechter Linn.

Bestëmmt d'Gréisst amplaz se unzehuelen. Liest d'MTU vum Tunnel mat ip link show tun0, schéckt duerno Proben, déi net fragmentéiert dierfe ginn: ping -4 -M do -s 1352 host, widderholl mat méi klengen Notzlaaschten. Eng Ännerung vum Feelschlag zum Erfolleg bei enger bestëmmter Gréisst ass e Beweis; en eenheetleche Feelschlag deit drop hin, datt ICMP gefiltert gëtt, a seet Iech näischt.

Eng temporär Reduktioun bestätegt d'Theorie séier, an eng dauerhaft Versioun gehéiert an de Profil oder als MSS-Klamp op de Router, deen den Tunnel weiderleet:

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

Déi zwou Ursaachen, déi e Gréissteproblem imitéieren

Eng Schlësselfichier, déi de Client net liese kann, produzéiert déiselwecht Waard, ouni Warnung och an der ausféierlecher Ausgab. E known_hosts-Muster mécht dat einfach: en @cert-authority-Andro, deen op e ëffentleche CA-Schlëssel weist, deen nëmmen ee Kont liese kann. De Kont, deem d'Fichier gehéiert, verbënnt sech, an all anere Kont hänkt. Wann de Feeler dem Benotzer an net dem Host follegt, kontrolléiert d'Fichiersmodi virun de Pakgréissten.

En Update kann och den Algorithmus ewechhuelen, deen déi zwou Säiten virdru gedeelt hunn. Fixéiert eng Method, déi de Server nach ubitt, als Diagnos: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Eng Verbindung, déi direkt geléngt, beweist, datt de Wee an der Rei ass, an d'Korrektur gehéiert an d'Verhandlungspolitik op béide Säiten.

Dräi Fakten, déi et wäert sinn opzeschreiwen

Schreift d'MTU vum Tunnel virun an no all Ännerung op, ob d'Kopéiere vun enger grousser Fichier bei enger widderhuelbarer Gréisst feelt a ob en Host ouni Zertifikat um selwechten Tunnel grad esou hänkt. Déi dräi Observatiounen trennen d'Gréisst vun den Erlaabnesser a vun der Verhandlung méi séier wéi en Stack Kommanden.

Si verhënneren och, datt déi nächst Persoun d'MTU erof setzt wéinst engem Feeler, deen ni iwwer d'Gréisst war.

Wann d'Bild nach ëmmer onkloer ass, test aus engem zweete Client um selwechten Tunnel. En Client, dee sech verbënnt, verréckelt de Feeler vum Wee an d'Konfiguratioun vun der éischter Maschinn.