Solution 1 :
Modifiez le MTU de l'interface réseau pour le résoudre. Il s'agit d'un bogue pour Ubuntu 14.04.
Cela a fonctionné pour moi :
sudo ip li set mtu 1200 dev wlan0
OU
sudo ifconfig wlan0 mtu 1200
ssh ne parvient pas à se connecter à l'hôte VPN - se bloque à 'en attente de SSH2_MSG_KEX_ECDH_REPLY'
Solution 2 :
Exactement le même problème ici pour accéder à un serveur dédié au centre de données online.net.
Il n'y a aucun problème après un redémarrage, pas besoin de changer de MTU, la connexion ssh fonctionne pendant 1-3 semaines, puis apparaît exactement le même bug, bloquant sur KEXINIT, plus possible de se connecter au serveur ssh.
Cela pourrait être une sorte de bogue sshd, mais il est nécessairement déclenché par des problèmes de réseau qui se produisent après 1 à 3 semaines, j'ai reproduit ce problème exact plusieurs fois avec de nombreux serveurs différents sur ce réseau, certains disent que cela pourrait être lié à un bogue 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 version de distribution, de configuration et de sshd.
si vous ne voulez pas redémarrer tous les 10 jours parce que les pare-feux du centre de données (ou d'autres ajustements du réseau) font des trucs bizarres :
connectez-vous d'abord avec l'une de ces solutions de contournement côté client :
solution de contournement 1, en réduisant votre MTU côté client local :
ip li set mtu 1400 dev wlan0
(1400 devrait suffire mais vous pouvez essayer d'utiliser des valeurs inférieures si nécessaire)
solution de contournement 2, en spécifiant le chiffrement choisi pour la connexion ssh :
ssh -c [email protected] host
(ou essayez avec n'importe quel autre chiffrement disponible)
Ces deux solutions de contournement côté client l'ont fait pour moi, je pouvais me connecter et économiser ma disponibilité ; mais vous voulez résoudre ce problème côté serveur, pour toujours, afin que vous n'ayez pas à demander à chaque client de modifier localement leur MTU.
Sur gentoo j'ai juste ajouté :
mtu_eth0="1400"
dans /etc/conf.d/net
(la même option mtu devrait être disponible quelque part dans votre fichier de configuration de réseau de distribution préféré)
J'ai réglé le mtu sur 1400, mais 1460 est probablement suffisant dans la plupart des cas.
une autre solution de contournement pourrait être d'utiliser les règles iptables suivantes pour gérer la fragmentation :
# /sbin/iptables -I SORTIE -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
# /sbin/ip6tables -I SORTIE -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
(mais je n'avais personnellement pas besoin de celui-ci jusqu'à maintenant)
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
edit mars 2016 :
-
abaisser le mtu à 1400 sur le serveur fonctionne presque toujours, mais j'ai récemment eu le cas où le mtu était déjà 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 en attendant que la page se recharge jusqu'à dire "le serveur a réinitialisé la connexion", également corrigé après que le client a défini le mtU sur 1400.
liens associés :
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
Solution 3 :
Dans mon cas, je n'ai pas la permission de réduire la taille du MTU. Et spécifier manuellement le Cipher ne fonctionne pas.
Je peux me connecter après avoir raccourci la liste des MAC en en spécifiant un, par exemple :
ssh -o MACs=hmac-sha2-256 <HOST>
Solution 4 :
J'ai eu le même problème après avoir mis à niveau ma machine cliente Ubuntu. J'ai résolu mon problème en réduisant la taille de la ligne "Ciphers" dans /etc/ssh/ssh_config. Cela fonctionne également si vous spécifiez le chiffrement dans la ligne de commande (ex :ssh -c [email protected])
Conseil d'ici :
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/708493/comments/39
Solution 5 :
J'ai commencé à avoir ce problème aujourd'hui, sur Windows (ssh distribué avec Git) et Ubuntu.
Cela semble être un bogue sur OpenSSH, il y a un problème sur LauchPad.
Cela a fonctionné pour moi sur Windows en forçant le chiffrement 3des-cbc et la clé sur Ubuntu.