SSH visí na SSH2_MSG_KEX_ECDH_REPLY: ne vždy je to MTU

Tunel je nahoru, banner dorazí a klient vypíše zprávu o čekání na odpověď výměny klíčů. Výsledky hledání ukazují přímo na MTU a někdy to platí. Často ne: odpověď možná nikdy nebyla odeslána, protože klient nemohl přečíst klíčový soubor nebo se obě strany nedohodly na algoritmu. Řádek popisuje, na co klient čeká, ne proč čekání začalo. Berte to jako symptom a oddělte tři příčiny, než změníte jakoukoli velikost.

Přečtěte si trasování, abyste viděli, zda byla odpověď vůbec očekávána

Podrobný výstup ukazuje poslední úspěšný krok před tichem. Pokud dorazil protokolový banner serveru, TCP funguje a vzdálený konec je živý; otevřenou otázkou je, co se stalo s jedním konkrétním paketem. Minuta ticha po banneru vypadá jako problém cesty. Zpráva o žádné odpovídající metodě výměny klíčů je problém politiky. Dlouhé čekání, které skončí zavřením relace serverem, znamená, že server to vzdal, a jeho log vysvětluje proč.

V posledním případě si před zásahem do klienta přečtěte autentizační log serveru. Klient nevidí rozhodnutí, které server nikdy neposlal.

Proč může být malá odpověď přesto příliš velká

Odpovědi výměny klíčů jsou obvykle drobné, takže obviňovat velikost zní špatně. U certifikátů hostitele odpověď drobná není, protože nese řetězec certifikátů serveru. To z ní dělá první paket v relaci, který může překročit použitelnou zátěž tunelu. Když se zpětná vazba objevování MTU cesty někde na trase ztratí, odesílatel stále znovu posílá paket, který se nevejde, a klient čeká věčně na stejném řádku.

Zjistěte velikost, místo abyste ji předpokládali. Přečtěte MTU tunelu pomocí ip link show tun0, pak posílejte sondy, které se nesmějí fragmentovat: ping -4 -M do -s 1352 host, opakované s menší zátěží. Změna ze selhání na úspěch při určité velikosti je důkaz; rovnoměrné selhání naznačuje, že ICMP je filtrován, a nic vám neříká.

Dočasné snížení teorii rychle potvrdí a trvalá verze patří do profilu nebo jako MSS omezení na routeru, který tunel předává:

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

Dvě příčiny, které napodobují problém velikosti

Klíčový soubor, který klient nedokáže přečíst, vytváří stejné čekání, bez varování i v podrobném výstupu. Jeden vzor v known_hosts to usnadňuje: záznam @cert-authority odkazující na veřejný klíč CA, který může přečíst jen jeden účet. Účet, který soubor vlastní, se připojí, a každý jiný účet visí. Pokud selhání sleduje uživatele, a ne hostitele, zkontrolujte režimy souboru před velikostmi paketů.

Aktualizace také může odstranit algoritmus, který obě strany dříve sdílely. Zafixujte jednu metodu, kterou server ještě nabízí, jako diagnostiku: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Spojení, které hned uspěje, dokazuje, že cesta je v pořádku, a oprava patří do vyjednávací politiky na obou stranách.

Tři fakta, která stojí za zapsání

Zapište MTU tunelu před každou změnou a po ní, zda kopírování velkého souboru selhává při opakovatelné velikosti a zda hostitel bez certifikátu na stejném tunelu zamrzne stejně. Tato tři pozorování oddělují velikost od oprávnění a od vyjednávání rychleji než hromada příkazů.

Také brání tomu, aby další člověk snížil MTU kvůli závadě, která nikdy nebyla o velikosti.

Pokud je obrázek stále nejasný, testujte z druhého klienta na stejném tunelu. Klient, který se připojí, přesouvá závadu z cesty do konfigurace prvního stroje.