SSH travaille dans du mastic mais pas terminal

Lorsque j'essaie de ssh ceci dans un terminal: ssh [email protected] j'ai l'erreur suivante:
Connection closed by 69.163.227.82

Lorsque j'utilise le mastic, je peux me connecter au serveur. Pourquoi cela se passe-t-il, et comment puis-je que cela fonctionne dans un terminal?

Ssh -v [email protected]

 OpenSSH_6.0p1 (CentrifyDC build 5.1.0-472) (CentrifyDC build 5.1.0-472), OpenSSL 0.9.8w 23 Apr 2012 debug1: Reading configuration data /etc/centrifydc/ssh/ssh_config debug1: /etc/centrifydc/ssh/ssh_config line 52: Applying options for * debug1: Connecting to sub.domain.com [69.163.227.82] port 22. debug1: Connection established. debug1: identity file /home/ryannaddy/.ssh/id_rsa type -1 debug1: identity file /home/ryannaddy/.ssh/id_rsa-cert type -1 debug1: identity file /home/ryannaddy/.ssh/id_dsa type -1 debug1: identity file /home/ryannaddy/.ssh/id_dsa-cert type -1 debug1: identity file /home/ryannaddy/.ssh/id_ecdsa type -1 debug1: identity file /home/ryannaddy/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5 debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH_5* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.0 debug1: Miscellaneous failure Cannot resolve network address for KDC in requested realm debug1: Miscellaneous failure Cannot resolve network address for KDC in requested realm debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP Connection closed by 69.163.227.82 

Solution trouvée pour moi via l'URL suivante: http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/

Il est même très utile d'expliquer ce qui se passe.

En fin de compte, j'ai ajouté ce qui suit à / etc / ssh / ssh_config:

 Host * SendEnv LANG LC_* HashKnownHosts yes GSSAPIAuthentication yes GSSAPIDelegateCredentials no Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc HostKeyAlgorithms ssh-rsa,ssh-dss MACs hmac-md5,hmac-sha1,hmac-ripemd160 

Ni Ciphers, ni HostKeyAlgorithms ont travaillé seul, mais les MAC sont très bien placés pour que cela fonctionne, mais je ne peux pas être sûr de mettre un peu de temps à le résoudre. J'espère que cela peut au moins aider quelqu'un d'autre.


Modifier: Cela (parfois) corrige le problème, mais probablement pas comme vous le souhaitez. –jcwenger

Ces paramètres semblent (comme effet secondaire) changer la manière dont le client ssh émet des paquets et provoque l'émission de petits paquets. Cela ne résout pas le problème; Il suffit, parfois, de le faire pour que le problème réel (fragmentation MTU interagissant avec les implémentations stupides de règles de pare-feu) ne soit pas déclenché.

La solution correcte consiste à définir un MTU qui fonctionne de bout en bout.

Le fait de mettre manuellement MTU sur un nombre plus petit pour s'assurer qu'aucune fragmentation ne se produit n'est pas un nettoyeur (nous, en tant qu'utilisateurs, n'auraient pas à prendre manuellement des mesures pour contrer les problèmes causés par nos équipes de réseau) … mais il traite au moins directement La cause réelle d'une manière fiable et factible, plutôt que de vider les paramètres de chiffrement de SSH d'une manière qui, comme effet secondaire, lorsque les étoiles s'alignent, provoque l'absence de gros paquets.

Aussi, SSH n'est pas la seule chose qui fait de gros paquets. Le réglage de MTU empêche la même chose de passer à d'autres protocoles.

Cela a fonctionné pour moi …

 ifconfig eth0 mtu 576 

http://fred-web.blogspot.com.au/2012/10/ssh-hang-on-expecting.html

Cela a corrigé le problème MTU sans avoir à coder un code, il le réparera pour ssh et tout autre protocole effectué par celui-ci. En tant que root, exécutez ce qui suit:

 echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing 

Vous pouvez en savoir plus sur le problème et la solution ici et ici .

Avez-vous regardé et trouvé la suggestion suivante ici :

Essayez de vous assurer que la ligne suivante dans votre / etc / ssh / ssh_config (PAS sshd_config) n'est pas commentée:

 Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc 

Vous devrez également essayer de renvoyer ce fichier à la valeur par défaut et essayer à nouveau, c'est-à-dire désinstaller et réinstaller openssh-client IIRC le nom du package.

Changez l'interface réseau MTU pour la résoudre. C'est un bug 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 attendant SSH2_MSG_KEX_ECDH_REPLY '

J'ai commencé à avoir ce problème aujourd'hui, sur Windows (ssh distribué avec Git) et Ubuntu.

Il semble que ce soit un bug 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.

J'ai pu résoudre ce problème en obligeant à utiliser IPv4 avec

 ssh -4 [email protected] 

Comme je suis sur un Mac, je ne sais pas quel est le paramètre MTU ici ou comment les modifier, mais j'ai pensé que d'autres pourraient en bénéficier.