SSH si blocca su SSH2_MSG_KEX_ECDH_REPLY: non è sempre l'MTU

Il tunnel è attivo, il banner arriva e il client stampa un messaggio sull'attesa della risposta dello scambio di chiavi. I risultati di ricerca puntano dritto all'MTU, e a volte è giusto. Spesso no: la risposta potrebbe non essere mai stata inviata, perché il client non riusciva a leggere un file di chiave o i due estremi non si sono mai accordati su un algoritmo. La riga descrive ciò che il client attende, non perché l'attesa è iniziata. Trattala come un sintomo e separa le tre cause prima di cambiare qualsiasi dimensione.

Leggi la traccia per vedere se una risposta era attesa

L'output dettagliato mostra l'ultimo passo riuscito prima del silenzio. Se il banner di protocollo del server è arrivato, TCP funziona e l'estremità remota è viva; la domanda aperta è cosa è successo a un pacchetto specifico. Un minuto di silenzio dopo il banner sembra un problema di percorso. Un messaggio su nessun metodo di scambio di chiavi corrispondente è un problema di politica. Un'attesa lunga che finisce con il server che chiude la sessione significa che il server ha rinunciato, e il suo log spiega perché.

Nell'ultimo caso, leggi il log di autenticazione del server prima di toccare il client. Il client non può vedere una decisione che il server non ha mai inviato.

Perché una risposta piccola può comunque essere troppo grande

Le risposte dello scambio di chiavi sono di solito minuscole, quindi dare la colpa alla dimensione suona sbagliato. Con i certificati host la risposta non è minuscola, perché porta la catena di certificati del server. Questo la rende il primo pacchetto della sessione che può superare il carico utile del tunnel. Quando il riscontro della scoperta dell'MTU di percorso si perde da qualche parte lungo la rotta, il mittente continua a ritrasmettere un pacchetto che non entra, e il client attende per sempre sulla stessa riga.

Determina la dimensione invece di presumerla. Leggi l'MTU del tunnel con ip link show tun0, poi invia sonde che non devono essere frammentate: ping -4 -M do -s 1352 host, ripetute con carichi più piccoli. Un passaggio da fallimento a successo a una dimensione precisa è una prova; un fallimento uniforme suggerisce che ICMP è filtrato e non ti dice nulla.

Una riduzione temporanea conferma subito la teoria, e una versione duratura appartiene al profilo o a un clamp MSS sul router che inoltra il tunnel:

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

Le due cause che imitano un problema di dimensione

Un file di chiave che il client non riesce a leggere produce la stessa attesa, senza avviso nemmeno nell'output dettagliato. Un pattern di known_hosts lo rende facile: una voce @cert-authority che punta a una chiave pubblica CA che solo un account può leggere. L'account proprietario del file si connette, e ogni altro account si blocca. Se il guasto segue l'utente invece dell'host, controlla i permessi del file prima delle dimensioni dei pacchetti.

Un aggiornamento può anche rimuovere l'algoritmo che i due estremi condividevano. Fissa un solo metodo che il server offre ancora come diagnostica: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Una connessione che riesce subito dimostra che il percorso è a posto e che la correzione appartiene alla politica di negoziazione di entrambe le parti.

Tre fatti che vale la pena annotare

Annota l'MTU del tunnel prima e dopo ogni modifica, se la copia di un file grande fallisce a una dimensione ripetibile e se un host senza certificato sullo stesso tunnel si blocca allo stesso modo. Quelle tre osservazioni separano la dimensione dai permessi e dalla negoziazione più in fretta di una pila di comandi.

Impediscono anche alla persona successiva di abbassare l'MTU per un guasto che non ha mai riguardato la dimensione.

Se il quadro è ancora poco chiaro, prova da un secondo client sullo stesso tunnel. Un client che si connette sposta il guasto dal percorso alla configurazione della prima macchina.