SSH se blokira na SSH2_MSG_KEX_ECDH_REPLY: nije uvijek MTU

Tunel je podignut, baner stigne, a klijent ispisuje poruku o čekanju na odgovor razmjene ključeva. Rezultati pretrage upućuju ravno na MTU, i ponekad je to tačno. Često nije: odgovor možda nikada nije poslan, jer klijent nije mogao pročitati datoteku ključa ili se strane nisu dogovorile o algoritmu. Red opisuje šta klijent čeka, a ne zašto je čekanje počelo. Tretirajte to kao simptom i odvojite tri uzroka prije nego što promijenite bilo koju veličinu.

Pročitajte trag da vidite je li odgovor uopće bio očekivan

Detaljni izlaz pokazuje posljednji uspješni korak prije tišine. Ako je stigao protokolni baner servera, TCP radi i udaljena strana je živa; otvoreno pitanje je šta se dogodilo s jednim određenim paketom. Minuta tišine nakon banera izgleda kao problem putanje. Poruka o nepostojanju odgovarajuće metode razmjene ključeva problem je politike. Dugo čekanje koje završi zatvaranjem sesije od strane servera znači da je server odustao, a njegov zapis objašnjava zašto.

U posljednjem slučaju pročitajte serverov zapis provjere autentičnosti prije nego što dirate klijenta. Klijent ne može vidjeti odluku koju server nikada nije poslao.

Zašto mali odgovor ipak može biti prevelik

Odgovori razmjene ključeva obično su sićušni, pa kriviti veličinu zvuči pogrešno. Uz certifikate hosta odgovor nije sićušan, jer nosi lanac certifikata servera. To ga čini prvim paketom u sesiji koji može premašiti upotrebljivi sadržaj tunela. Kada se povratna informacija otkrivanja MTU putanje negdje na ruti izgubi, pošiljalac stalno ponovo šalje paket koji ne može stati, a klijent čeka zauvijek na istom redu.

Utvrdite veličinu umjesto da je pretpostavljate. Pročitajte MTU tunela s ip link show tun0, zatim pošaljite probe koje se ne smiju fragmentirati: ping -4 -M do -s 1352 host, ponovljene s manjim sadržajem. Promjena od neuspjeha do uspjeha pri određenoj veličini dokaz je; ujednačen neuspjeh upućuje na to da je ICMP filtriran i ne govori vam ništa.

Privremeno smanjenje brzo potvrđuje teoriju, a trajna verzija pripada profilu ili MSS ograničenju na ruteru koji prosljeđuje 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 uzroka koja oponašaju problem veličine

Datoteka ključa koju klijent ne može pročitati proizvodi isto čekanje, bez upozorenja čak i u detaljnom izlazu. Jedan obrazac u known_hosts-u to olakšava: unos @cert-authority koji pokazuje na javni ključ CA koji samo jedan račun može pročitati. Račun koji posjeduje datoteku se povezuje, a svaki drugi račun se blokira. Ako neuspjeh prati korisnika, a ne host, provjerite načine datoteke prije veličina paketa.

Nadogradnja također može ukloniti algoritam koji su obje strane dijelile. Fiksirajte jednu metodu koju server još nudi kao dijagnostiku: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Veza koja odmah uspije dokazuje da je putanja u redu i da popravka pripada politici pregovaranja na obje strane.

Tri činjenice koje vrijedi zapisati

Zabilježite MTU tunela prije i poslije svake promjene, pada li kopiranje velike datoteke pri ponovljivoj veličini i blokira li se host bez certifikata na istom tunelu jednako. Ta tri zapažanja odvajaju veličinu od dozvola i od pregovaranja brže od hrpe komandi.

Ona također sprječavaju sljedeću osobu da smanji MTU zbog kvara koji nikada nije bio vezan za veličinu.

Ako slika još nije jasna, testirajte s drugog klijenta na istom tunelu. Klijent koji se poveže pomjera kvar s putanje na konfiguraciju prve mašine.