SSH trava em SSH2_MSG_KEX_ECDH_REPLY: nem sempre é a MTU

O túnel está ativo, o banner chega e o cliente imprime uma mensagem sobre esperar pela resposta da troca de chaves. Os resultados de pesquisa apontam direto para a MTU, e às vezes isso está certo. Muitas vezes não: a resposta pode nunca ter sido enviada, porque o cliente não conseguiu ler um arquivo de chave ou os dois lados nunca concordaram com um algoritmo. A linha descreve o que o cliente espera, não por que a espera começou. Trate-a como um sintoma e separe as três causas antes de mudar qualquer tamanho.

Leia o rastro para ver se alguma resposta era esperada

A saída detalhada mostra o último passo bem-sucedido antes do silêncio. Se o banner de protocolo do servidor chegou, o TCP está funcionando e o lado remoto está vivo; a questão aberta é o que aconteceu com um pacote específico. Um minuto de silêncio após o banner parece um problema de caminho. Uma mensagem sobre nenhum método de troca de chaves correspondente é um problema de política. Uma espera longa que termina com o servidor fechando a sessão significa que o servidor desistiu, e o log dele explica por quê.

No último caso, leia o log de autenticação do servidor antes de tocar no cliente. O cliente não pode ver uma decisão que o servidor nunca enviou.

Por que uma resposta pequena ainda pode ser grande demais

As respostas da troca de chaves costumam ser minúsculas, então culpar o tamanho soa errado. Com certificados de host a resposta não é minúscula, porque carrega a cadeia de certificados do servidor. Isso a torna o primeiro pacote da sessão que pode exceder a carga útil do túnel. Quando o feedback da descoberta de MTU de caminho se perde em algum ponto da rota, o emissor continua reenviando um pacote que não cabe, e o cliente espera para sempre na mesma linha.

Determine o tamanho em vez de supor. Leia a MTU do túnel com ip link show tun0 e envie sondas que não devem ser fragmentadas: ping -4 -M do -s 1352 host, repetidas com cargas menores. Uma mudança de falha para sucesso num tamanho específico é evidência; falha uniforme sugere que o ICMP está filtrado e não lhe diz nada.

Uma redução temporária confirma a teoria rapidamente, e uma versão duradoura pertence ao perfil ou a um clamp MSS no roteador que encaminha 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 duas causas que imitam um problema de tamanho

Um arquivo de chave que o cliente não consegue ler produz a mesma espera, sem aviso mesmo na saída detalhada. Um padrão de known_hosts facilita isso: uma entrada @cert-authority apontando para uma chave pública de CA que só uma conta consegue ler. A conta dona do arquivo conecta, e todas as outras contas travam. Se a falha segue o usuário e não o host, verifique os modos do arquivo antes dos tamanhos de pacote.

Uma atualização também pode remover o algoritmo que os dois lados compartilhavam. Fixe um único método que o servidor ainda oferece como diagnóstico: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Uma conexão que tem sucesso imediatamente prova que o caminho está bom e que a correção pertence à política de negociação dos dois lados.

Três fatos que vale a pena anotar

Anote a MTU do túnel antes e depois de qualquer mudança, se a cópia de um arquivo grande falha num tamanho repetível e se um host sem certificado no mesmo túnel trava da mesma forma. Essas três observações separam o tamanho das permissões e da negociação mais rápido que uma pilha de comandos.

Elas também impedem que a próxima pessoa baixe a MTU por uma falha que nunca teve a ver com tamanho.

Se o quadro ainda não estiver claro, teste a partir de um segundo cliente no mesmo túnel. Um cliente que se conecta move a falha do caminho para a configuração da primeira máquina.