debug1: attend SSH2_MSG_KEX_DH_GEX_GROUP

8

J'ai deux serveurs A et B. A et B peuvent ssh entre eux et d'autres serveurs mais ne peuvent pas ssh dans le serveur C. Tous les serveurs peuvent ssh dans A et B (y compris le serveur C) La demande raccroche à ce qui suit:

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

et finalement expire. Si je fais un, netstat -aje vois une connexion établie sur le serveur C et le serveur A ou B. Lorsque je ferme la session sur le serveur C, je vois une tentative de connexion mais je ne termine jamais. Je peux ping aussi bien que traceroute dans les deux sens.

ssh Steve
la source
1
Vous trouverez une réponse plus détaillée ici: superuser.com/questions/568891/…
Cormite

Réponses:

5

J'ai trouvé le même problème.

Dans mon cas:

  • Version SSH du client: OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 janvier 201
  • Version SSH du serveur: OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 février 2013

Il semble qu'il y ait un problème lié à cette version de serveur ssh car j'utilise le même client avec beaucoup de systèmes distants différents sans aucun problème.

Après de nombreux tests avec des valeurs MTU, j'ai finalement trouvé que la solution était de supprimer hmac-md5 de la liste des algorithmes MAC.

En /etc/ssh/ssh_configéditant la ligne suivante:

#   MACs hmac-md5,hmac-sha1,[email protected],hmac-ripemd160
MACs hmac-sha1

J'espère que cela t'aidera.

dgaavl
la source
1
Votant pour le simple fait que vous ayez mentionné MTU, qui a résolu mon problème ... pour être précis, ma session ssh a transité des interfaces routées avec différents MTU. J'ai corrigé le routage asymétrique et cela a également résolu le problème.
Mike Pennington
J'ai eu ce bogue sur Debian Jessie et cela l'a corrigé.
2

ajouter -c aes256-ctr

solution via http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/

J'ai découvert ce problème aujourd'hui en essayant de me connecter à une nouvelle pile LAPP bitnami (OpenSSH_5.9p1 Debian-5ubuntu1.4 pat OpenSSH_5 *) à partir de l'AWS Store à partir d'un Mac exécutant 10.9.4 (OpenSSH_6.2p2, OSSLShim 0.9.8r 8 décembre 2011 ).

user1383619
la source
2
Ajoutez-le à quoi? Le détail est toujours apprécié.
Falcon Momot
Cela marche. Une solution plus racine semble être la désactivation des trames jumbo sur mon ordinateur client OS X le résout également sans avoir à court-circuiter la suite de chiffrement.
Brian Reiter