Az SSH elakad az SSH2_MSG_KEX_ECDH_REPLY üzenetnél: nem mindig az MTU a hibás

Az alagút él, a banner megérkezik, és a kliens üzenetet ír ki arról, hogy a kulcscsere válaszára vár. A keresési találatok egyenesen az MTU-ra mutatnak, és ez néha helyes. Gyakran nem az: a válasz lehet, hogy soha nem indult el, mert a kliens nem tudott beolvasni egy kulcsfájlt, vagy a két fél soha nem egyezett meg egy algoritmusban. A sor azt írja le, mire vár a kliens, nem azt, miért kezdődött a várakozás. Kezelje tünetként, és válassza külön a három okot, mielőtt bármilyen méretet módosítana.

Olvassa el a nyomkövetést, hogy lássa, egyáltalán várt-e választ

A részletes kimenet a csend előtti utolsó sikeres lépést mutatja. Ha a szerver protokollbannerje megérkezett, a TCP működik és a távoli oldal él; a nyitott kérdés az, mi történt egy adott csomaggal. A banner utáni egyperces csend útvonalproblémának tűnik. A nem egyező kulcscsere-módszerről szóló üzenet szabályzatprobléma. A hosszú várakozás, amely a szerver munkamenet-bezárásával végződik, azt jelenti, hogy a szerver feladta, és a naplója megmagyarázza, miért.

Az utolsó esetben olvassa el a szerver hitelesítési naplóját, mielőtt a klienshez nyúl. A kliens nem láthat olyan döntést, amelyet a szerver soha nem küldött el.

Miért lehet egy kis válasz mégis túl nagy

A kulcscsere válaszai általában aprók, ezért a méret hibáztatása helytelenül hangzik. Gazdagép-tanúsítványokkal a válasz nem apró, mert a szerver tanúsítványláncát hordozza. Ez teszi a munkamenet első csomagjává, amely meghaladhatja az alagút használható hasznos terhét. Amikor az útvonal-MTU felderítésének visszajelzése valahol az útvonalon elvész, a küldő újra és újra olyan csomagot küld, amely nem fér bele, és a kliens örökké ugyanazon a soron vár.

Határozza meg a méretet, ne feltételezze. Olvassa ki az alagút MTU-ját az ip link show tun0 paranccsal, majd küldjön olyan próbákat, amelyeket nem szabad töredezni: ping -4 -M do -s 1352 host, kisebb hasznos terhekkel ismételve. A kudarcból sikerbe való átmenet egy adott méreten bizonyíték; az egyenletes kudarc arra utal, hogy az ICMP szűrve van, és semmit nem mond Önnek.

Az ideiglenes csökkentés gyorsan megerősíti az elméletet, a tartós változat pedig a profilba vagy az alagutat továbbító router MSS-korlátozásába tartozik:

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

A két ok, amely mérethatárolási problémát utánoz

Az a kulcsfájl, amelyet a kliens nem tud beolvasni, ugyanazt a várakozást okozza, figyelmeztetés nélkül még a részletes kimenetben is. Egy known_hosts-minta ezt megkönnyíti: egy @cert-authority bejegyzés, amely egy CA nyilvános kulcsára mutat, amelyet csak egy fiók tud beolvasni. A fájlt birtokló fiók csatlakozik, és minden más fiók elakad. Ha a hiba a felhasználót követi, nem a gazdagépet, ellenőrizze a fájlmódokat a csomagméretek előtt.

Egy frissítés eltávolíthatja azt az algoritmust is, amelyet a két fél korábban megosztott. Rögzítsen egy módszert, amelyet a szerver még kínál, diagnosztikaként: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Az azonnal sikeres kapcsolat bizonyítja, hogy az útvonal rendben van, és a javítás a két oldal tárgyalási szabályzatába tartozik.

Három tény, amelyet érdemes feljegyezni

Jegyezze fel az alagút MTU-ját minden változtatás előtt és után, hogy egy nagy fájl másolása egy ismételhető méreten meghiúsul-e, és hogy ugyanazon az alagúton egy tanúsítvány nélküli gazdagép ugyanúgy elakad-e. Ez a három megfigyelés gyorsabban választja el a méretet a jogosultságoktól és a tárgyalástól, mint egy halom parancs.

Azt is megakadályozzák, hogy a következő ember csökkentse az MTU-t egy olyan hiba miatt, amely soha nem a méretről szólt.

Ha a kép még mindig nem tiszta, teszteljen egy második kliensről ugyanazon az alagúton. Az a kliens, amelyik csatlakozik, a hibát az útvonalról az első gép konfigurációjára helyezi át.