Impossible SSH: debug1: attend SSH2_MSG_KEX_DH_GEX_REPLY
Nous avons un serveur XXX SUR Amazon EC2.
SSH s'exécute sur un port standard (22).
J'ai placé ma clé de pub dans le fichier /.ssh/authorized_keys
Ce qui est amusant, c'est qu'HIER, cela fonctionnait très bien!
Mais aujourd'hui, je ne sais pas ce qui s'est passé! Je ne peux tout simplement pas me connecter.
ssh -vvvv nom_serveur
est coincé
debug1: attend SSH2_MSG_KEX_DH_GEX_REPLY
J'ai vérifié ma clé de pub et c'est là! (comment j'ai vérifié ?? j'ai demandé à l'autre gars de vérifier)
puis j'ai utilisé un autre ordinateur (windows 7 + PuTTY) et placé ma nouvelle pubkey. Et quoi? J'ai pu me connecter! Et c'est un autre ordinateur avec Win7 est sur le même LAN, ce qui signifie que l'adresse IP externe est la même.
Ma clé privée fonctionne pour d'autres serveurs mais pas avec cela.
Aidez-moi!
Modifiez l'interface réseau MTU 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
OR
Sudo ifconfig wlan0 mtu 1200
ssh ne parvient pas à se connecter à l'hôte VPN - se bloque à "attend SSH2_MSG_KEX_ECDH_REPLY"
Même problème ici pour accéder à un serveur dédié dans le centre de données online.net.
Theres aucun problème après un redémarrage, pas besoin de changer MTU, la connexion ssh fonctionne pendant 1-3 semaines, puis apparaît exactement ce même bogue, bloquant sur KEXINIT, plus possible de connecter le serveur ssh.
Il pourrait s'agir d'une sorte de bogue sshd, mais cela est nécessairement déclenché par des choses nework 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 qu'il pourrait être lié à un bogue Cisco, éventuellement 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-feu du centre de données (ou d'autres ajustements du réseau) font des choses étranges:
connectez-vous d'abord à l'une de ces solutions de contournement côté client:
solution de contournement 1, 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 plus faibles si nécessaire)
solution de contournement 2, en spécifiant le chiffre choisi pour la connexion ssh:
ssh -c [email protected] Host
(ou essayez avec un autre chiffrement disponible)
Ces deux solutions de contournement côté client l'ont fait pour moi, je pouvais me connecter et économiser mon temps de disponibilité; mais vous voulez corriger ce problème côté serveur, pour toujours, vous n'avez donc pas à demander à chaque client de modifier localement leur MTU.
Sur gentoo, je viens d'ajouter:
mtu_eth0="1400"
dans /etc/conf.d/net
(la même option mtu devrait être disponible quelque part dans votre fichier de configuration réseau de distribution préféré)
J'ai mis le MTU à 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 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 je n'avais personnellement pas besoin de celui-ci 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
modifier mars 2016:
abaisser le mtu à 1400 sur le serveur fonctionne le plus souvent, mais j'ai récemment eu le cas où mtu était déjà abaissé à 1400 sur le serveur et le problème est réapparu, et le client a également dû abaisser mtu à 1400.
Le problème est également apparu sur les formulaires de connexion Web en attendant que la page soit rechargée jusqu'à ce que "le serveur ait réinitialisé la connexion", également résolu après que le client ait défini la mtU sur 1400.
liens connexes :
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1254085
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
Dans mon cas, je n'ai pas la permission de réduire la taille MTU. Et la spécification manuelle du chiffre ne fonctionne pas.
Je peux me connecter après avoir raccourci la liste des MAC en en spécifiant une, par exemple:
ssh -o MACs=hmac-sha2-256 <Host>
J'ai eu le même problème après avoir mis à niveau ma machine client 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 chiffre dans la ligne de commande (ex: ssh -c username @ hostname)
Astuce d'ici:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/708493/comments/39
Changer le KexAlgorithm a fonctionné pour moi, et pourrait être une option où vous n'avez pas les droits système pour modifier les paramètres MTU. Cela pourrait également être un problème pour l'équipe d'OpenSSH. par exemple.
ssh -o KexAlgorithms=ecdh-sha2-nistp521 [email protected]
J'ai commencé à avoir ce problème aujourd'hui, sur Windows (ssh distribué avec Git) et Ubuntu.
Il semble que ce soit un bogue sur OpenSSH, il y a un problème sur LauchPad .
Cela a fonctionné pour moi sur Windows forçant le chiffrement 3des-cbc et la clé sur Ubuntu.