SSH hang by SSH2_MSG_KEX_ECDH_REPLY: dit is nie altyd die MTU nie

Die tonnel is op, die banier kom deur, en die kliënt druk 'n boodskap dat hy op die sleuteluitruil-antwoord wag. Soekresultate wys dadelik na die MTU, en soms is dit reg. Dikwels is dit nie: die antwoord is dalk nooit gestuur nie, omdat die kliënt 'n sleutellêer nie kon lees nie of die twee kante dit nie oor 'n algoritme eens kon word nie. Die reël beskryf waarop die kliënt wag, nie waarom die wag begin het nie. Behandel dit as 'n simptoom en skei die drie oorsake voordat jy enige grootte verander.

Lees die spoor om te sien of 'n antwoord hoegenaamd verwag is

Uitgebreide uitvoer wys die laaste suksesvolle stap voor die stilte. As die bediener se protokolbanier aangekom het, werk TCP en leef die ander kant; die oop vraag is wat met een spesifieke pakket gebeur het. 'n Minuut stilte ná die banier lyk soos 'n padprobleem. 'n Boodskap oor geen ooreenstemmende sleuteluitruilmetode is 'n beleidsprobleem. 'n Lang wag wat eindig met die bediener wat die sessie sluit, beteken die bediener het opgegee, en sy log verduidelik waarom.

Lees in die laaste geval die bediener se ouditlog voordat jy aan die kliënt raak. Die kliënt kan nie 'n besluit sien wat die bediener nooit gestuur het nie.

Waarom 'n klein antwoord steeds te groot kan wees

Sleuteluitruil-antwoorde is gewoonlik piepklein, so om die grootte te blameer klink verkeerd. Met sertifikate van die bediener is die antwoord nie klein nie, want dit dra die bediener se sertifikaatketting. Dit maak dit die eerste pakket in die sessie wat die tonnel se bruikbare loonvrag kan oorskry. Wanneer pad-MTU-ontdekkingsterugvoer êrens langs die roete laat val word, hou die sender 'n pakket wat nie pas nie, oor en oor stuur, en wag die kliënt vir ewig op dieselfde reël.

Bepaal die grootte in plaas daarvan om dit te aanvaar. Lees die tonnel se MTU met ip link show tun0, stuur dan proewe wat nie mag fragmenteer nie: ping -4 -M do -s 1352 host, herhaal met kleiner loonvragte. 'n Verandering van mislukking na sukses by 'n spesifieke grootte is bewys; eenvormige mislukking dui daarop dat ICMP gefiltreer word en sê vir jou niks.

'n Tydelike verlaging bevestig die teorie vinnig, en 'n blywende weergawe hoort in die profiel of as 'n MSS-klamp op die router wat die tonnel aanstuur:

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 twee oorsake wat 'n grootteprobleem naboots

'n Sleutellêer wat die kliënt nie kan lees nie, veroorsaak dieselfde wag, sonder enige waarskuwing selfs in uitgebreide uitvoer. Een known_hosts-patroon maak dit maklik om te raak: 'n @cert-authority-inskrywing wat na 'n CA-openbare sleutel wys wat net een rekening kan lees. Die rekening wat die lêer besit, verbind, en elke ander rekening hang. As die fout die gebruiker volg eerder as die bediener, kyk na lêermodusse voordat jy na pakketgroottes kyk.

'n Opgradering kan ook die algoritme verwyder wat albei kante vroeër gedeel het. Pen een metode vas wat die bediener nog bied as 'n diagnostikum: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. 'n Verbinding wat dadelik slaag, bewys die pad is reg en die regstelling hoort in die onderhandelingsbeleid aan albei kante.

Drie feite wat die moeite werd is om neer te skryf

Teken die tonnel se MTU voor en ná enige verandering aan, of 'n groot lêerkopie by 'n herhaalbare grootte misluk, en of 'n sertifikaatvrye bediener op dieselfde tonnel net so vasval. Daardie drie waarnemings skei grootte van toestemmings en van onderhandeling vinniger as 'n stapel opdragte.

Hulle verhoed ook dat die volgende persoon die MTU verlaag vir 'n fout wat nooit oor grootte gegaan het nie.

As die prentjie nog onduidelik is, toets van 'n tweede kliënt op dieselfde tonnel. 'n Kliënt wat verbind, skuif die fout van die pad na die eerste masjien se konfigurasie.