Même problème pour accéder à un serveur dédié au centre de données online.net.
Il n'y a pas de problème après un redémarrage, pas besoin de changer le MTU, la connexion ssh fonctionne pendant 1-3 semaines, puis apparaît exactement le même bug, blocage sur KEXINIT, plus possible de se connecter au serveur ssh.
Il pourrait s'agir d'une sorte de bug sshd, mais il est nécessairement déclenché par un nouveau travail qui se produit après 1-3 semaines, j'ai reproduit ce problème exact à plusieurs reprises avec de nombreux serveurs différents sur ce réseau, certains disent que cela pourrait être lié à un bug cisco, peut-être lié à certaines options DPI.
Ce problème ne s'est jamais produit avec d'autres serveurs que je gère dans d'autres centres de données, et qui ont exactement la même distro, la même configuration et la même version de sshd.
si vous ne voulez pas redémarrer tous les 10 jours parce que les pare-feu du centre de données (ou d'autres réglages de réseau) font des choses bizarres :
d'abord se connecter avec l'une de ces solutions de contournement côté client :
solution 1, diminuer votre MTU local, côté client :
ip li set mtu 1400 dev wlan0
( 1400 devrait suffire mais vous pouvez essayer d'utiliser des valeurs plus basses si nécessaire )
solution 2, en spécifiant le cryptage choisi pour la connexion ssh :
ssh -c aes256-gcm@openssh.com host
(ou essayez avec n'importe quel autre cryptogramme disponible)
Ces deux solutions de contournement côté client m'ont permis de me connecter et d'économiser mon temps de fonctionnement ; mais vous voulez résoudre ce problème côté serveur, pour toujours, afin de ne pas avoir à demander à chaque client d'ajuster localement son MTU.
Sur gentoo, j'ai simplement ajouté :
mtu_eth0="1400"
dans /etc/conf.d/net
(la même option mtu devrait être disponible quelque part dans le fichier de configuration réseau de votre distro préférée)
J'ai fixé le mtu à 1400, mais 1460 est probablement suffisant dans la plupart des cas.
une autre solution pourrait être d'utiliser les règles iptables suivantes pour gérer la fragmentation :
# /sbin/iptables -I OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
# /sbin/ip6tables -I OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
( mais personnellement, je n'en avais pas besoin jusqu'à présent )
Notez également que les symptômes de ce problème peuvent également être :
debug1: SSH2_MSG_KEXINIT sent
pas seulement
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
éditer mars 2016 :
-
abaisser le mtu à 1400 sur le serveur fonctionne presque toujours, mais j'ai récemment eu le cas où le mtu avait déjà été abaissé à 1400 sur le serveur et le problème est réapparu, et le client a également dû abaisser le mtu à 1400.
-
Le problème est également apparu sur les formulaires de connexion web, qui attendaient que la page se recharge avant de dire "le serveur a réinitialisé la connexion". Le problème a également été résolu après que le client a réglé le mtU sur 1400.
liens connexes :
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1254085
http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/
https://nowhere.dk/articles/natty-narwhal-problems-connecting-to-servers-behind-cisco-firewalls-using-ssh
https://stackoverflow.com/questions/2419412/ssh-connection-stop-at-debug1-ssh2-msg-kexinit-sent
http://www.1-script.com/forums/ssh/ssh-hang-after-ssh2-msg-kexinit-sent-10616-.htm
http://www.snailbook.com/faq/mtu-mismatch.auto.html
