SSH es penja a SSH2_MSG_KEX_ECDH_REPLY: no sempre és l'MTU

El túnel està aixecat, el bàner arriba i el client imprimeix un missatge sobre l'espera de la resposta de l'intercanvi de claus. Els resultats de cerca apunten directament a l'MTU, i de vegades és cert. Sovint no ho és: potser la resposta no es va enviar mai, perquè el client no va poder llegir un fitxer de clau o els dos extrems no es van posar d'acord en un algorisme. La línia descriu què espera el client, no per què va començar l'espera. Tracteu-ho com un símptoma i separeu les tres causes abans de canviar cap mida.

Llegiu el rastre per veure si s'esperava cap resposta

La sortida detallada mostra l'últim pas correcte abans del silenci. Si ha arribat el bàner de protocol del servidor, TCP funciona i l'extrem remot és viu; la qüestió oberta és què va passar amb un paquet concret. Un minut de silenci després del bàner sembla un problema de camí. Un missatge sobre cap mètode d'intercanvi de claus coincident és un problema de política. Una espera llarga que acaba amb el servidor tancant la sessió vol dir que el servidor s'ha rendit, i el seu registre explica per què.

En l'últim cas, llegiu el registre d'autenticació del servidor abans de tocar el client. El client no pot veure una decisió que el servidor no va enviar mai.

Per què una resposta petita encara pot ser massa gran

Les respostes d'intercanvi de claus solen ser minúscules, així que culpar la mida sona malament. Amb certificats d'amfitrió la resposta no és minúscula, perquè porta la cadena de certificats del servidor. Això la converteix en el primer paquet de la sessió que pot superar la càrrega útil del túnel. Quan el retorn de descoberta d'MTU del camí es perd en algun punt de la ruta, l'emissor reenvia sense parar un paquet que no hi cap, i el client espera per sempre a la mateixa línia.

Determineu la mida en lloc de suposar-la. Llegiu l'MTU del túnel amb ip link show tun0, i després envieu probes que no s'hagin de fragmentar: ping -4 -M do -s 1352 host, repetides amb càrregues més petites. Un canvi de fallada a èxit en una mida concreta és una prova; una fallada uniforme suggereix que ICMP està filtrat i no us diu res.

Una reducció temporal confirma la teoria de seguida, i una versió duradora pertany al perfil o a un clamp MSS al router que encamina el túnel:

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

Les dues causes que imiten un problema de mida

Un fitxer de clau que el client no pot llegir produeix la mateixa espera, sense cap avís ni tan sols a la sortida detallada. Un patró de known_hosts ho fa fàcil: una entrada @cert-authority que apunta a una clau pública de CA que només un compte pot llegir. El compte propietari del fitxer es connecta, i tots els altres comptes es pengen. Si la fallada segueix l'usuari i no l'amfitrió, comproveu els modes del fitxer abans que les mides dels paquets.

Una actualització també pot eliminar l'algorisme que tots dos extrems compartien. Fixeu un sol mètode que el servidor encara ofereixi com a diagnòstic: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Una connexió que té èxit immediatament demostra que el camí està bé i que la correcció pertany a la política de negociació d'ambdues bandes.

Tres fets que val la pena anotar

Anoteu l'MTU del túnel abans i després de qualsevol canvi, si la còpia d'un fitxer gran falla a una mida repetible i si un amfitrió sense certificat al mateix túnel s'encalla igual. Aquestes tres observacions separen la mida dels permisos i de la negociació més de pressa que un munt d'ordres.

També eviten que la propera persona baixi l'MTU per una fallada que mai no va ser de mida.

Si la imatge encara no és clara, proveu des d'un segon client al mateix túnel. Un client que es connecta mou la fallada del camí a la configuració de la primera màquina.