SSH se bloquea en SSH2_MSG_KEX_ECDH_REPLY: no siempre es la MTU

El túnel está activo, llega el banner y el cliente imprime un mensaje sobre la espera de la respuesta del intercambio de claves. Los resultados de búsqueda apuntan directo a la MTU, y a veces es correcto. A menudo no: puede que la respuesta nunca se enviara, porque el cliente no pudo leer un archivo de clave o los dos extremos nunca acordaron un algoritmo. La línea describe qué espera el cliente, no por qué empezó la espera. Trátela como un síntoma y separe las tres causas antes de cambiar cualquier tamaño.

Lea la traza para ver si se esperaba alguna respuesta

La salida detallada muestra el último paso correcto antes del silencio. Si llegó el banner de protocolo del servidor, TCP funciona y el extremo remoto está vivo; la pregunta abierta es qué pasó con un paquete concreto. Un minuto de silencio tras el banner parece un problema de ruta. Un mensaje sobre ningún método de intercambio de claves coincidente es un problema de política. Una espera larga que termina con el servidor cerrando la sesión significa que el servidor se rindió, y su registro explica por qué.

En el último caso, lea el registro de autenticación del servidor antes de tocar el cliente. El cliente no puede ver una decisión que el servidor nunca envió.

Por qué una respuesta pequeña puede seguir siendo demasiado grande

Las respuestas del intercambio de claves suelen ser diminutas, así que culpar al tamaño suena mal. Con certificados de host la respuesta no es diminuta, porque lleva la cadena de certificados del servidor. Eso la convierte en el primer paquete de la sesión que puede superar la carga útil del túnel. Cuando la realimentación del descubrimiento de MTU de ruta se pierde en algún punto del recorrido, el emisor sigue reenviando un paquete que no cabe, y el cliente espera para siempre en la misma línea.

Determine el tamaño en vez de suponerlo. Lea la MTU del túnel con ip link show tun0 y luego envíe sondas que no deban fragmentarse: ping -4 -M do -s 1352 host, repetidas con cargas más pequeñas. Un cambio de fallo a éxito en un tamaño concreto es una prueba; un fallo uniforme sugiere que ICMP está filtrado y no le dice nada.

Una reducción temporal confirma la teoría rápidamente, y una versión duradera corresponde al perfil o a un clamp MSS en el router que reenvía 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

Las dos causas que imitan un problema de tamaño

Un archivo de clave que el cliente no puede leer produce la misma espera, sin aviso incluso en la salida detallada. Un patrón de known_hosts lo hace fácil: una entrada @cert-authority que apunta a una clave pública de CA que solo una cuenta puede leer. La cuenta propietaria del archivo se conecta, y todas las demás cuentas se cuelgan. Si el fallo sigue al usuario y no al host, compruebe los modos del archivo antes que los tamaños de paquete.

Una actualización también puede eliminar el algoritmo que ambos extremos compartían. Fije un solo método que el servidor aún ofrezca como diagnóstico: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Una conexión que tiene éxito de inmediato demuestra que la ruta está bien y que la corrección pertenece a la política de negociación de ambos lados.

Tres datos que vale la pena anotar

Anote la MTU del túnel antes y después de cualquier cambio, si la copia de un archivo grande falla en un tamaño repetible y si un host sin certificado en el mismo túnel se atasca igual. Esas tres observaciones separan el tamaño de los permisos y de la negociación más rápido que un montón de comandos.

También impiden que la siguiente persona baje la MTU por un fallo que nunca tuvo que ver con el tamaño.

Si la imagen sigue sin estar clara, pruebe desde un segundo cliente en el mismo túnel. Un cliente que se conecta traslada el fallo de la ruta a la configuración de la primera máquina.