SSH blijft hangen bij SSH2_MSG_KEX_ECDH_REPLY: het is niet altijd de MTU

De tunnel staat, de banner komt binnen en de client drukt een bericht af over wachten op het antwoord van de sleuteluitwisseling. Zoekresultaten wijzen direct naar de MTU, en soms is dat juist. Vaak niet: het antwoord is misschien nooit verzonden, omdat de client een sleutelbestand niet kon lezen of de twee kanten het nooit eens werden over een algoritme. De regel beschrijft waarop de client wacht, niet waarom het wachten begon. Behandel het als een symptoom en scheid de drie oorzaken voordat u welke grootte dan ook wijzigt.

Lees de trace om te zien of er überhaupt een antwoord werd verwacht

Uitgebreide uitvoer toont de laatste geslaagde stap voor de stilte. Als de protocolbanner van de server is aangekomen, werkt TCP en leeft de andere kant; de open vraag is wat er met één specifiek pakket is gebeurd. Een minuut stilte na de banner lijkt op een padprobleem. Een bericht over geen overeenkomende sleuteluitwisselmethode is een beleidsprobleem. Een lang wachten dat eindigt met het sluiten van de sessie door de server betekent dat de server het opgaf, en zijn log legt uit waarom.

Lees in het laatste geval het authenticatielog van de server voordat u de client aanraakt. De client kan geen beslissing zien die de server nooit heeft verzonden.

Waarom een klein antwoord toch te groot kan zijn

Antwoorden bij sleuteluitwisseling zijn meestal piepklein, dus de grootte de schuld geven klinkt verkeerd. Met hostcertificaten is het antwoord niet piepklein, omdat het de certificaatketen van de server draagt. Daardoor is het het eerste pakket in de sessie dat de bruikbare payload van de tunnel kan overschrijden. Wanneer feedback van pad-MTU-ontdekking ergens op de route verloren gaat, blijft de afzender een pakket opnieuw verzenden dat niet past, en de client wacht voor altijd op dezelfde regel.

Stel de grootte vast in plaats van haar aan te nemen. Lees de MTU van de tunnel met ip link show tun0, stuur dan probes die niet gefragmenteerd mogen worden: ping -4 -M do -s 1352 host, herhaald met kleinere payloads. Een verandering van mislukking naar succes bij een bepaalde grootte is bewijs; gelijkmatige mislukking wijst erop dat ICMP wordt gefilterd en zegt u niets.

Een tijdelijke verlaging bevestigt de theorie snel, en een blijvende versie hoort in het profiel of als MSS-clamp op de router die de tunnel doorstuurt:

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

De twee oorzaken die een grootteprobleem nabootsen

Een sleutelbestand dat de client niet kan lezen geeft hetzelfde wachten, zonder waarschuwing zelfs in uitgebreide uitvoer. Eén known_hosts-patroon maakt dit makkelijk: een @cert-authority-item dat wijst naar een openbare CA-sleutel die slechts één account kan lezen. Het account dat het bestand bezit, maakt verbinding, en elk ander account blijft hangen. Als de fout de gebruiker volgt in plaats van de host, controleer dan bestandsmodi voordat u naar pakketgroottes kijkt.

Een upgrade kan ook het algoritme verwijderen dat beide kanten eerder deelden. Pin één methode die de server nog biedt als diagnose: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Een verbinding die meteen slaagt, bewijst dat het pad in orde is en dat de oplossing in het onderhandelingsbeleid aan beide kanten hoort.

Drie feiten die het opschrijven waard zijn

Noteer de MTU van de tunnel voor en na elke wijziging, of het kopiëren van een groot bestand mislukt bij een herhaalbare grootte en of een host zonder certificaat op dezelfde tunnel op dezelfde manier vastloopt. Die drie observaties scheiden grootte van machtigingen en van onderhandeling sneller dan een stapel commando's.

Ze voorkomen ook dat de volgende persoon de MTU verlaagt voor een fout die nooit over grootte ging.

Als het beeld nog onduidelijk is, test dan vanaf een tweede client op dezelfde tunnel. Een client die verbinding maakt, verplaatst de fout van het pad naar de configuratie van de eerste machine.