SSH bloquéase en SSH2_MSG_KEX_ECDH_REPLY: non sempre é a MTU

O túnel está activo, chega o banner e o cliente imprime unha mensaxe sobre a espera da resposta do intercambio de claves. Os resultados de busca apuntan directamente á MTU, e ás veces é certo. A miúdo non: pode que a resposta nunca se enviase, porque o cliente non puido ler un ficheiro de clave ou os dous extremos nunca acordaron un algoritmo. A liña describe o que espera o cliente, non por que comezou a espera. Trátea como un síntoma e separa as tres causas antes de cambiar calquera tamaño.

Lea a traza para ver se se esperaba algunha resposta

A saída detallada mostra o último paso correcto antes do silencio. Se chegou o banner de protocolo do servidor, TCP funciona e o extremo remoto está vivo; a pregunta aberta é que pasou cun paquete concreto. Un minuto de silencio tras o banner parece un problema de ruta. Unha mensaxe sobre ningún método de intercambio de claves coincidente é un problema de política. Unha espera longa que remata co servidor pechando a sesión significa que o servidor se rendeu, e o seu rexistro explica por que.

No último caso, lea o rexistro de autenticación do servidor antes de tocar o cliente. O cliente non pode ver unha decisión que o servidor nunca enviou.

Por que unha resposta pequena aínda pode ser demasiado grande

As respostas do intercambio de claves adoitan ser minúsculas, así que culpar o tamaño soa mal. Con certificados de host a resposta non é minúscula, porque leva a cadea de certificados do servidor. Iso convértea no primeiro paquete da sesión que pode superar a carga útil do túnel. Cando a realimentación do descubrimento de MTU de ruta se perde nalgún punto do percorrido, o emisor segue reenviando un paquete que non cabe, e o cliente espera para sempre na mesma liña.

Determine o tamaño en vez de supoñelo. Lea a MTU do túnel con ip link show tun0 e despois envía sondas que non deben fragmentarse: ping -4 -M do -s 1352 host, repetidas con cargas máis pequenas. Un cambio de fallo a éxito nun tamaño concreto é unha proba; un fallo uniforme suxire que ICMP está filtrado e non lle di nada.

Unha redución temporal confirma a teoría de inmediato, e unha versión duradeira pertence ao perfil ou a un clamp MSS no router que encamiña o 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

As dúas causas que imitan un problema de tamaño

Un ficheiro de clave que o cliente non pode ler produce a mesma espera, sen aviso mesmo na saída detallada. Un patrón de known_hosts fáiselo doado: unha entrada @cert-authority que apunta a unha clave pública de CA que só unha conta pode ler. A conta propietaria do ficheiro conéctase, e todas as demais contas colgan. Se o fallo segue o usuario e non o host, comprobe os modos do ficheiro antes que os tamaños de paquete.

Unha actualización tamén pode eliminar o algoritmo que ambos os extremos compartían. Fixe un só método que o servidor aínda ofreza como diagnóstico: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Unha conexión que ten éxito de inmediato demostra que a ruta está ben e que a corrección pertence á política de negociación de ambas as partes.

Tres datos que paga a pena anotar

Anote a MTU do túnel antes e despois de calquera cambio, se a copia dun ficheiro grande falla nun tamaño repetible e se un host sen certificado no mesmo túnel se atasca igual. Esas tres observacións separan o tamaño dos permisos e da negociación máis rápido que un montón de ordes.

Tamén impiden que a seguinte persoa baixe a MTU por un fallo que nunca tivo que ver co tamaño.

Se a imaxe segue sen estar clara, probe desde un segundo cliente no mesmo túnel. Un cliente que se conecta traslada o fallo da ruta á configuración da primeira máquina.