SSH se bloque sur SSH2_MSG_KEX_ECDH_REPLY : ce n'est pas toujours le MTU

Le tunnel est monté, la bannière arrive et le client affiche un message d'attente de la réponse d'échange de clés. Les résultats de recherche pointent droit sur le MTU, et c'est parfois juste. Souvent non : la réponse n'a peut-être jamais été envoyée, parce que le client n'a pas pu lire un fichier de clé ou que les deux extrémités ne se sont jamais mises d'accord sur un algorithme. La ligne décrit ce que le client attend, pas pourquoi l'attente a commencé. Traitez-la comme un symptôme et séparez les trois causes avant de changer la moindre taille.

Lisez la trace pour voir si une réponse était seulement attendue

La sortie détaillée montre la dernière étape réussie avant le silence. Si la bannière de protocole du serveur est arrivée, TCP fonctionne et l'extrémité distante est vivante ; la question ouverte est ce qui est arrivé à un paquet précis. Une minute de silence après la bannière ressemble à un problème de chemin. Un message sur l'absence de méthode d'échange de clés correspondante est un problème de politique. Une longue attente qui se termine par la fermeture de la session par le serveur signifie que le serveur a renoncé, et son journal explique pourquoi.

Dans ce dernier cas, lisez le journal d'authentification du serveur avant de toucher au client. Le client ne peut pas voir une décision que le serveur n'a jamais envoyée.

Pourquoi une petite réponse peut quand même être trop grande

Les réponses d'échange de clés sont normalement minuscules, donc accuser la taille semble faux. Avec des certificats d'hôte, la réponse n'est pas minuscule, car elle porte la chaîne de certificats du serveur. Cela en fait le premier paquet de la session susceptible de dépasser la charge utile du tunnel. Quand le retour de découverte du MTU de chemin se perd quelque part sur la route, l'émetteur renvoie sans cesse un paquet qui ne peut pas passer, et le client attend indéfiniment à la même ligne.

Établissez la taille au lieu de la supposer. Lisez le MTU du tunnel avec ip link show tun0, puis envoyez des sondes qui ne doivent pas être fragmentées : ping -4 -M do -s 1352 host, répétées avec des charges plus petites. Un passage de l'échec au succès à une taille précise est une preuve ; un échec uniforme suggère qu'ICMP est filtré et ne vous apprend rien.

Une réduction temporaire confirme vite la théorie, et une version durable appartient au profil ou à un clamp MSS sur le routeur qui achemine le 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

Les deux causes qui imitent un problème de taille

Un fichier de clé que le client ne peut pas lire produit la même attente, sans avertissement même en sortie détaillée. Un motif de known_hosts rend cela facile : une entrée @cert-authority pointant vers une clé publique d'AC que seul un compte peut lire. Le compte propriétaire du fichier se connecte, et tous les autres comptes se bloquent. Si la panne suit l'utilisateur plutôt que l'hôte, vérifiez les modes du fichier avant les tailles de paquets.

Une mise à jour peut aussi supprimer l'algorithme que les deux extrémités partageaient. Épinglez une seule méthode que le serveur propose encore comme diagnostic : ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Une connexion qui réussit aussitôt prouve que le chemin est bon et que le correctif relève de la politique de négociation des deux côtés.

Trois faits qui valent la peine d'être notés

Notez le MTU du tunnel avant et après tout changement, si la copie d'un gros fichier échoue à une taille reproductible et si un hôte sans certificat sur le même tunnel se bloque de la même manière. Ces trois observations séparent la taille des permissions et de la négociation plus vite qu'une pile de commandes.

Elles empêchent aussi la personne suivante de baisser le MTU pour une panne qui n'a jamais concerné la taille.

Si l'image reste floue, testez depuis un second client sur le même tunnel. Un client qui se connecte déplace la panne du chemin vers la configuration de la première machine.