SSH zamrzne na SSH2_MSG_KEX_ECDH_REPLY: nie vždy je to MTU

Tunel je hore, banner príde a klient vypíše správu o čakaní na odpoveď výmeny kľúčov. Výsledky hľadania ukazujú priamo na MTU a niekedy to platí. Často nie: odpoveď možno nikdy nebola odoslaná, pretože klient nedokázal prečítať kľúčový súbor alebo sa obe strany nikdy nedohodli na algoritme. Riadok opisuje, na čo klient čaká, nie prečo čakanie začalo. Berte to ako príznak a oddeľte tri príčiny, kým zmeníte akúkoľvek veľkosť.

Prečítajte trasovanie, aby ste zistili, či sa odpoveď vôbec očakávala

Podrobný výstup ukazuje posledný úspešný krok pred tichom. Ak dorazil protokolový banner servera, TCP funguje a vzdialený koniec je živý; otvorenou otázkou je, čo sa stalo s jedným konkrétnym paketom. Minúta ticha po banneri vyzerá ako problém cesty. Správa o žiadnej zodpovedajúcej metóde výmeny kľúčov je problém politiky. Dlhé čakanie, ktoré sa skončí zavretím relácie serverom, znamená, že server to vzdal, a jeho log vysvetľuje prečo.

V poslednom prípade si pred zásahom do klienta prečítajte autentifikačný log servera. Klient nevidí rozhodnutie, ktoré server nikdy neposlal.

Prečo malá odpoveď môže byť napriek tomu príliš veľká

Odpovede pri výmene kľúčov sú zvyčajne drobné, takže obviňovanie veľkosti znie nesprávne. S certifikátmi hostiteľa odpoveď nie je drobná, pretože nesie reťazec certifikátov servera. To z nej robí prvý paket relácie, ktorý môže prekročiť použiteľnú záťaž tunela. Keď sa spätná väzba objavovania MTU cesty niekde na trase stratí, odosielateľ stále znova posiela paket, ktorý sa nezmestí, a klient čaká večne na tom istom riadku.

Zistite veľkosť, namiesto toho, aby ste ju predpokladali. Prečítajte MTU tunela pomocou ip link show tun0, potom posielajte sondy, ktoré sa nesmú fragmentovať: ping -4 -M do -s 1352 host, opakované s menšou záťažou. Zmena zo zlyhania na úspech pri určitej veľkosti je dôkaz; rovnomerné zlyhanie naznačuje, že ICMP je filtrované, a nič vám nehovorí.

Dočasné zníženie rýchlo potvrdí teóriu a trvalá verzia patrí do profilu alebo ako obmedzenie MSS na routeri, ktorý tunel preposiela:

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

Dve príčiny, ktoré napodobňujú problém veľkosti

Kľúčový súbor, ktorý klient nedokáže prečítať, vytvára rovnaké čakanie, bez varovania aj v podrobnom výstupe. Jeden vzor v known_hosts to uľahčuje: záznam @cert-authority odkazujúci na verejný kľúč CA, ktorý môže prečítať iba jeden účet. Účet, ktorý súbor vlastní, sa pripojí a každý iný účet visí. Ak zlyhanie sleduje používateľa a nie hostiteľa, skontrolujte režimy súboru pred veľkosťami paketov.

Aktualizácia tiež môže odstrániť algoritmus, ktorý obe strany predtým zdieľali. Zafixujte jednu metódu, ktorú server ešte ponúka, ako diagnostiku: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Spojenie, ktoré hneď uspeje, dokazuje, že cesta je v poriadku, a oprava patrí do vyjednávacej politiky na oboch stranách.

Tri fakty, ktoré stoja za zapísanie

Zapíšte MTU tunela pred každou zmenou a po nej, či kopírovanie veľkého súboru zlyháva pri opakovateľnej veľkosti a či hostiteľ bez certifikátu na tom istom tuneli zamrzne rovnako. Tie tri pozorovania oddeľujú veľkosť od oprávnení a od vyjednávania rýchlejšie ako hromada príkazov.

Tiež bránia tomu, aby ďalší človek znížil MTU pre závadu, ktorá nikdy nebola o veľkosti.

Ak je obraz stále nejasný, testujte z druhého klienta na tom istom tuneli. Klient, ktorý sa pripojí, presúva závadu z cesty do konfigurácie prvého stroja.