SSH se ustavi pri SSH2_MSG_KEX_ECDH_REPLY: ni vedno MTU

Tunel deluje, baner prispe in odjemalec izpiše sporočilo o čakanju na odgovor izmenjave ključev. Rezultati iskanja kažejo naravnost na MTU, in včasih je to pravilno. Pogosto ni: odgovor morda nikoli ni bil poslan, ker odjemalec ni mogel prebrati ključne datoteke ali se strani nista nikoli dogovorili o algoritmu. Vrstica opisuje, na kaj odjemalec čaka, ne zakaj se je čakanje začelo. Obravnavajte jo kot simptom in ločite tri vzroke, preden spremenite kakršno koli velikost.

Preberite sled, da vidite, ali je bil odgovor sploh pričakovan

Podroben izpis pokaže zadnji uspešni korak pred tišino. Če je baner protokola strežnika prispel, TCP deluje in oddaljeni konec je živ; odprto vprašanje je, kaj se je zgodilo z enim določenim paketom. Minuta tišine po banerju je videti kot težava poti. Sporočilo o nobeni ustrezni metodi izmenjave ključev je težava politike. Dolgo čakanje, ki se konča z zaprtjem seje s strani strežnika, pomeni, da je strežnik obupal, in njegov dnevnik pojasni zakaj.

V zadnjem primeru preberite dnevnik preverjanja pristnosti strežnika, preden se dotaknete odjemalca. Odjemalec ne more videti odločitve, ki je strežnik ni nikoli poslal.

Zakaj je majhen odgovor lahko vseeno prevelik

Odgovori pri izmenjavi ključev so običajno drobceni, zato je kriviti velikost videti napačno. S potrdili gostitelja odgovor ni drobcen, ker nosi verigo potrdil strežnika. To ga naredi za prvi paket v seji, ki lahko preseže uporabno obremenitev tunela. Ko se povratna informacija odkrivanja MTU poti nekje na poti izgubi, pošiljatelj kar naprej pošilja paket, ki ne gre noter, in odjemalec čaka večno v isti vrstici.

Ugotovite velikost, namesto da bi jo domnevali. Preberite MTU tunela s ip link show tun0, nato pošljite sonde, ki se ne smejo fragmentirati: ping -4 -M do -s 1352 host, ponovljene z manjšimi obremenitvami. Sprememba od neuspeha do uspeha pri določeni velikosti je dokaz; enakomeren neuspeh kaže, da je ICMP filtriran, in vam ne pove ničesar.

Začasno zmanjšanje hitro potrdi teorijo, trajna različica pa spada v profil ali kot omejitev MSS na usmerjevalniku, ki posreduje tunel:

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

Dva vzroka, ki posnemata težavo velikosti

Ključna datoteka, ki je odjemalec ne more prebrati, ustvari isto čakanje, brez opozorila tudi v podrobnem izpisu. En vzorec v known_hosts to olajša: vnos @cert-authority, ki kaže na javni ključ CA, ki ga lahko prebere le en račun. Račun, ki ima datoteko, se poveže, vsak drug račun pa se ustavi. Če napaka sledi uporabniku in ne gostitelju, preverite načine datoteke pred velikostmi paketov.

Posodobitev lahko tudi odstrani algoritem, ki sta si ga oba konca prej delila. Pripnite eno metodo, ki jo strežnik še ponuja, kot diagnostiko: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Povezava, ki takoj uspe, dokazuje, da je pot v redu in da popravek spada v pogajalsko politiko na obeh straneh.

Tri dejstva, ki jih velja zapisati

Zapišite MTU tunela pred vsako spremembo in po njej, ali kopiranje velike datoteke spodleti pri ponovljivi velikosti in ali se gostitelj brez potrdila na istem tunelu ustavi enako. Ta tri opažanja ločijo velikost od dovoljenj in od pogajanj hitreje kot kup ukazov.

Preprečijo tudi, da bi naslednja oseba znižala MTU zaradi okvare, ki nikoli ni bila povezana z velikostjo.

Če slika še vedno ni jasna, preizkusite z drugega odjemalca na istem tunelu. Odjemalec, ki se poveže, premakne okvaro s poti v konfiguracijo prvega stroja.