Impossible SSH: debug1: attend SSH2_MSG_KEX_DH_GEX_REPLY


24

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 + mastic) et placé ma nouvelle clé de pub. 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.

Veuillez aider!


J'ai généré de nouvelles clés et stocké de nouvelles pubs ... la même chose! Ha!
bakytn

fyi, votre problème n'a rien à voir avec l'authentification par clé publique: l'échange de clés DH ( SSH2_MSG_KEX_DH_GEX_REPLY) se produit beaucoup plus tôt dans la connexion.
grawity

Merci pour l'information. BTW GUYS, le problème a été résolu par lui-même. Je n'ai rien essayé juste de me connecter et j'ai réussi. hah
bakytn

Mauvaise latence du réseau? beaucoup de gouttes? C'est juste un message normal.
Korjavin Ivan

c'est probablement le cas. Je ne peux plus le reproduire maintenant. Donc ça pourrait de mon côté.
bakytn

Réponses:


28

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

OU

sudo ifconfig wlan0 mtu 1200

ssh ne parvient pas à se connecter à l'hôte VPN - se bloque à «attend SSH2_MSG_KEX_ECDH_REPLY»


sudo ip li set mtu 1400 dev eno1travaillé pour moi sur Ubuntu 16.04.
Márcio

Merci beaucoup. Je n'ai pas pu SSH ou bureau à distance dans une boîte particulière pendant des semaines. HTTP fonctionne et les machines adjacentes fonctionnent bien. J'ai dû sauter des autres machines pour entrer.
duckbrain

12

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.

Cela pourrait être 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, 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 plus faibles si nécessaire)

solution de contournement 2, en spécifiant le chiffre choisi pour la connexion ssh:

ssh -c aes256-gcm@openssh.com 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 enregistrer ma disponibilité; mais vous voulez corriger ce problème côté serveur, pour toujours, donc vous n'avez 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

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

/programming/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


cela peut se produire en particulier lorsque vous avez un petit MTU très inhabituel côté client, par exemple si vous souhaitez utiliser openvpn sur un réseau double nat.
Dennis Nolte

j'ai utilisé les valeurs par défaut de mtu avant d'avoir ce problème, abaisser le mtu était la solution, pas le problème. veuillez expliquer votre commentaire.
neofutur

9

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>

Je savais que ça ne serait pas le MTU. Si quelqu'un joue avec le MTU côté serveur, cela peut affecter le débit du réseau. Le problème doit être une certaine différence de version d'OpenSSH et comment ils préfèrent certains cyphers et combinaisons de fonctions MAC.
Csaba Toth le


2

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.


2

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 une question que l'équipe OpenSSH devrait aborder. par exemple

ssh -o KexAlgorithms=ecdh-sha2-nistp521 fu@bar.com

-1

nous l'avons résolu en commentant la ligne Ciphers sur / etc / ssh / ssh_config


-2

Il semble clair que la boîte de dialogue des options pose problème, car j'ai modifié l'ordre dans lequel Putty négocie l'échange de clés et le problème résolu.


1
Qu'est-ce qui semble clair? Cette question a reçu une réponse (avec une réponse acceptée) il y a plus de 4 ans.
David Makogon

-3

cmiiw

  • vérifiez votre autorisation ~ / .ssh / authorized_keys, elle devrait être de 600

  • vérifiez le sur / var / log / secure, / var / log / messages ou / var / log / auth


L' authorized_keysautorisation n'a rien à voir avec l'erreur car le client est bloqué pendant la négation du protocole précédent. La vérification des journaux côté serveur peut aider, mais cette ligne est plutôt un commentaire - downvote.
try-catch-finally
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.