web-dev-qa-db-fra.com

SSH fonctionne dans PuTTY mais pas dans les terminaux

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

Lorsque j'utilise PuTTY, je peux me connecter au serveur. Pourquoi cela se produit-il et comment puis-je le faire fonctionner 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
linuxsshterminalputty
23
Get Off My Lawn

Solution trouvée pour moi via l'URL suivante: http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client- connexion réinitialisée par l'homologue/

Cela explique même très bien ce qui se passe.

Finalement, 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 n'ont fonctionné de manière autonome, je suis presque sûr que les MAC me permettent de tout mettre en œuvre pour que cela fonctionne, mais je ne peux pas en être sûr, j'ai mis de nombreuses heures à résoudre ce problème. J'espère que cela peut au moins aider quelqu'un d'autre.

Edit: Ceci corrige (parfois) le problème, mais probablement pas comme vous le souhaitez. - jcwenger

Ces paramètres semblent (comme un effet secondaire) changer la façon dont le client ssh émet des paquets et lui faire émettre des paquets plus petits. Cela ne résout pas le problème. parfois, il suffit que le vrai problème (fragmentation de MTU interagissant avec des implémentations de règles de pare-feu stupides) ne soit pas déclenché.

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

Avoir à définir manuellement un nombre plus petit de MTU pour éviter toute fragmentation n'est pas un nettoyeur (en tant qu'utilisateurs, nous ne devrions pas avoir à prendre des mesures manuellement pour contrer les problèmes causés par nos équipes réseau) ... mais au moins, il s’agit au moins directement de la cause réelle d’une manière fiable et prouvable, plutôt que de modifier les paramètres de chiffrement de SSH de manière à ce que l’effet secondaire, lorsque les étoiles s’alignent, de ne pas la rendre grosse paquets.

De plus, SSH n'est pas la seule chose qui fait de gros paquets. La définition de MTU empêche la même chose d’arriver avec d’autres protocoles.

23
mattw

Cela a fonctionné pour moi ...

ifconfig eth0 mtu 576

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

8
jagguli

Cela corrigeait le problème du MTU sans avoir à coder en dur une valeur, cela le corrigera pour ssh et pour tout autre protocole effectué par cela. 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 .

5
Marwan Alsabbagh

Certains ont-ils cherché et ont trouvé la suggestion suivante ici :

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

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

Vous pouvez également essayer de rétablir ce fichier par défaut et d’essayer à nouveau, c’est-à-dire désinstaller et réinstaller openssh-client IIRC le nom du paquet.

1
LawrenceC

Changez le MTU d'interface réseau pour le 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 à l'attente de SSH2_MSG_KEX_ECDH_REPLY '

1
shgnInc

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

ssh -4 [email protected]

Depuis que je suis sur Mac, je ne sais pas quels sont les paramètres de MTU ni comment les changer, mais je pense que d’autres pourraient en tirer parti.

1
Bruno Kim

Un peu d'une nécro ici, mais je l'ai rencontré sur OpenSSH_7.8p1, sur Linux. L’introduction du marquage DSCP dans les versions récentes d’OpenSSH semble s’être déclenchée dans VMware NAT (la mise en réseau pontée était satisfaisante dans les liens ci-dessous).

Vous pouvez contourner ce problème pour le moment en ajoutant/définissant ce qui suit dans /etc/ssh/ssh_config :

IPQoS lowdelay throughput

Des facteurs supplémentaires pourraient être que PuTTY (ou d'autres clients SSH distincts) ne rencontrent peut-être pas le problème du même hôte et votre MTU vérifie jusqu'à présent. c'est à dire.:

ping -M do -s 1472 your-ssh-server

Ces messages étaient particulièrement utiles et m'ont amené à l'endroit où je devais être:

https://groups.google.com/forum/#!topic/opensshunixdev/5FK67SCpPg8https: // groups.google.com/forum/#!topic/opensshunixdev/uNd48nGOe7A

0
Kachunkachunk

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

Il semble y avoir un bogue sur OpenSSH, il y a un problème sur LauchPad .

Cela a fonctionné pour moi sous Windows en forçant le chiffrement 3des-cbc et la clé sous Ubuntu.

0
LawfulHacker