SSH fonctionne en mastic mais pas en terminal

24

Quand j'essaye de ssh ceci dans un terminal: ssh username@sub.domain.comj'obtiens l'erreur suivante:
Connection closed by 69.163.227.82

Lorsque j'utilise du mastic, je peux me connecter au serveur. Pourquoi cela se produit-il et comment puis-je le faire fonctionner dans un terminal?

ssh -v nomutilisateur@sub.domain.com

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
linux  ssh  terminal  putty 
— Descendre ma pelouse
source
Que ssh -v username@sub.domain.commontre-t-on?
— James Sneeringer
J'ai mis à jour la question principale. Le serveur doit également demander un mot de passe, aucune clé ssh n'est requise pour se connecter.
— Descendez de ma pelouse
Avez-vous modifié des paramètres par défaut dans PuTTY?
— Kruug
Avez-vous également essayé user@domain.com? Oubliez le sub.
— Kruug
1
Vous utilisez la version d'OpenSSH de Centrify, ce qui implique que votre système est intégré à AD. Active Directory utilise Kerberos, et OpenSSH se plaint de ne pas trouver le Kerberos KDC, donc il se renfloue. A quoi ressemble ton /etc/krb5.conflook?
— James Sneeringer

Réponses:

23

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 explique même assez 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é par eux-mêmes, je suis sûr que les MAC m'ont mis au dessus pour que cela fonctionne, mais je ne peux pas ê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: Cela résout (parfois) le problème, mais probablement pas de la manière que vous souhaitez. --jcwenger

Ces paramètres semblent (en tant qu'effet secondaire) changer la façon dont le client ssh émet des paquets, et il se trouve qu'il provoque l'émission de petits paquets. Cela ne résout pas le problème; parfois, cela fait en sorte que le vrai problème (fragmentation MTU interagissant avec des implémentations de règles de pare-feu stupides) ne soit pas déclenché.

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

Devoir définir manuellement MTU sur un nombre plus petit pour garantir qu'aucune fragmentation ne se produit n'est pas plus propre (nous, en tant qu'utilisateurs, ne devrions pas avoir à prendre manuellement des mesures pour contrer les problèmes causés par nos équipes de réseau) ... mais cela traite au moins directement avec la cause réelle d'une manière fiable et prouvable, plutôt que de bousiller les paramètres de chiffrement de SSH de manière à ce que, comme effet secondaire, lorsque les étoiles s'alignent, il arrive qu'il ne fasse pas de gros 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 de se produire avec d'autres protocoles.

— mattw
source
5
merci, dans mon cas, la dernière ligne MACs hmac-md5,hmac-sha1,hmac-ripemd160suffisait
— Tombart
J'ai eu un problème avec github - git pull / git push - rien ne s'est passé. J'ai essayé ssh -T -v git@github.com et obtenu la même erreur. Utilisé cela pour le résoudre. Merci!
— Jason
J'ai eu un problème similaire et j'ai essayé cette solution. Un effet secondaire est que toute connexion à un hôte connu accuserait alors un changement de clé d'hôte.
— lfagundes
Tous ces patchs traitent le symptôme et non la cause. La réduction de la taille du chiffrement a le potentiel d'empêcher la fragmentation du MTU ... qui est le vrai problème, soulevé par @jagguli ci-dessous.
— jcwenger
L'ajout de la ligne "HostKeyAlgorithms ssh-rsa, ssh-dss" dans / etc / ssh / ssh_config a résolu mon problème de ne pas pouvoir SSH dans un modem Zyxel. Toutes les autres lignes de la tetbox ci-dessus étaient déjà en place sur ma machine. Merci pour le tuyau!
— Jeff Wright
6

Cela a résolu le problème MTU sans avoir à coder en dur une valeur, il le corrigera pour ssh et 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 .

— Marwan Alsabbagh
source
Explication: "Il s'avère que le système de fichiers noyau / proc fournit un moyen simple d'activer et de désactiver le test TCP MTU en modifiant une valeur dans le fichier" / proc / sys / net / ipv4 / tcp_mtu_probing. Une valeur de 0 = désactivé ; 1 = activé lorsqu'un routeur trou noir est détecté; 2 = toujours activé. "
— Jorj
1

Avez-vous regardé et 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 réessayer, c'est-à-dire désinstaller et réinstaller openssh-clientIIRC le nom du package.

— LawrenceC
source
Cela ne l'a pas résolu :(
— Get Off My Lawn
1

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

ssh -4 username@host.xyz

Étant donné que je suis sur un Mac, je ne sais pas quels sont les paramètres MTU ici ni comment les modifier, mais j'ai pensé que d'autres pourraient en bénéficier.

— Bruno Kim
source
Cette option oblige ssh à utiliser IP4 uniquement. Je suis également sur Mac et cela n'a PAS résolu mon problème.
— Jorj
0

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.

— LawfulHacker
source
0

Un peu 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 se déclencher dans VMware NAT (la mise en réseau pontée a été mentionnée pour être correcte dans les liens ci-dessous).

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

IPQoS lowdelay throughput

Des facteurs supplémentaires seraient que PuTTY (ou d'autres clients SSH distincts) peut ne pas rencontrer 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 ont été particulièrement utiles et m'ont amené là où je devais être:

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

— Kachunkachunk
source
-2

ssh -c aes256-ctr fonctionne très bien;

— udara
source
Pourquoi pensez-vous que cette commande résoudra le problème?
— Scott
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.