ssh_exchange_identification: read: connexion réinitialisée par un pair

107

Je suis sur OS X en train d’essayer de ssh sur un serveur Ubuntu 12.04. J'ai pu entrer dans SSH - jusqu'à ce que les choses s'arrêtent brusquement. J'ai lu en ligne pour utiliser le -vpour déboguer ceci. La sortie est indiquée ci-dessous. Si je ssh dans une boîte différente, puis ssh de cette boîte au serveur, je peux me connecter. Je ne sais pas comment résoudre ce problème, mais j'aimerais apprendre.

$ ssh -v me@server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to server [IP] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Connection reset by peer

Jusqu'à présent (sur les conseils des forums de discussion), j'ai recherché un fichier de refus d'hôtes - mais ce fichier n'existe pas sur ma machine.

$ cat /etc/hosts.deny 
cat: /etc/hosts.deny: No such file or directory

J'ai un accès administrateur sur la machine cliente mais pas sur le serveur.

ssh

— bernie2436
source

Je recommanderais de démarrer une sshdécoute sur un autre port, avec une sortie commentée, et de fournir la sortie lorsque vous essayez de vous y connecter. $(which sshd) -d -p 23. Si vous ne pouvez pas faire cela, vos options sont assez limitées. Le mieux est de trouver quelqu'un qui a les droits d'administrateur sur le serveur.

— Patrick

Se pourrait-il que l'administrateur du serveur limite votre accès pour une raison quelconque? En tout état de cause, je pourrais contacter cette personne.

— MDPC

12

Les fichiers hosts.deny et hosts.allow doivent être vérifiés sur le serveur , pas sur le client. En outre, les journaux du système sur le serveur doivent être vérifiés. Si vous n’y avez pas accès non plus, vous pouvez contacter l’administrateur du serveur afin d’y jeter un coup d’œil.

— Ckujau

Avez-vous trouvé une solution? quel était le problème?

— MeV

2

Était une liste hosts.deny qui a été remplie par l'administrateur avec un script automatique. Comme j'ai oublié mon mot de passe à un moment donné, j'ai eu quelques tentatives de connexion infructueuses, c'est-à-dire quand mon adresse IP a été ajoutée à la liste hosts.deny. Voilà pour la productivité d'une sécurité trop zélée.

— K.-Michael Aye

25

La modification abrupte peut résulter d'une modification du fichier de configuration sur la sshdconfiguration du serveur , mais vous indiquez que vous ne pouvez pas vérifier ou modifier cela sans le droit d'administrateur. Vous pouvez toujours essayer ce qui suit si les administrateurs du serveur ne peuvent pas être atteints (à temps).

Votre journal indique uniquement la chaîne de version locale, vous devez vérifier les versions de l’ sshdexécution sur le serveur et la machine intermédiaire.

Si ces versions diffèrent (en particulier entre la machine locale et le serveur et moins entre la machine intermédiaire et le serveur), il peut y avoir une incompatibilité de négociation, ce qui s'est déjà produit dans ssh. Auparavant, la solution consistait à raccourcir les entrées Ciphers, HostKeyAlgorithms et / ou MAC, sur la ligne de commande ( ssh -c aes256-ctr, etc.) ou dans votre /etc/ssh/ssh_config.

Vous devez rechercher dans les informations de débogage (lors de la connexion via l’intermédiaire au serveur) les valeurs appropriées en tant qu’argument pour la ligne de commande -c/ Ciphers, -o HostKeyAlgorithms/ HostKeyAlgorithmset -m/ MACsresp. ssh_config change.

Je n'ai pas eu ce problème moi-même pendant un moment, mais le IIRC qui me suffisait suffisait pour forcer manuellement le paramètre Ciphers et HostKeyAlgorithms, après quoi je pouvais mettre à jour la sshdversion du serveur et le problème disparaîtrait.

— Anthon
source

3

Dans mon cas, le sshdpackage de serveur a été mis à jour vers une version plus récente et entraîne une incompatibilité avec la sshconfiguration actuelle de mon client, comme vous l'avez dit. Effacer mes anciens sshfichiers de configuration a fait l'affaire. Cela devrait être la réponse acceptée.

— chakrit

2

@chakrit comment avez-vous nettoyé vos anciens fichiers de configuration ssh?

— Jonathan

@ Jonathan j'ai monté un disque de récupération pour le faire.

— chakrit

16

Vous avez peut-être été banni par fail2banou denyhosts. Dans un tel cas (et aussi pour le vérifier), si vous ne souhaitez pas vous soucier de l'aide de votre fournisseur de serveur, vous devez vous connecter à votre serveur à partir d'une autre adresse IP: par exemple, un autre serveur, la connexion à domicile d'un ami ou un serveur. point d'accès wifi, ou en utilisant SSH avec TOR.

Une fois connecté, vérifiez que votre adresse IP apparaît bien /etc/hosts.deny(côté serveur). Si c'est le cas, alors fail2banou denyhostsdoit être le coupable.

Voir les réponses à cette question pour la procédure à suivre denyhostspour éviter de bloquer votre adresse en permanence. Pour fail2bantrouver votre iptables -L --line-numberadresse IP avec et casser votre adresse IP avec iptables -D <chain> <chain number>, vérifiez les détails sur howtoforge .

Vous voudrez peut-être ajouter votre adresse IP à fail2banet vos denyhostslistes blanches (respectivement /etc/fail2ban/jail.conf, line ignoreipet /var/lib/denyhosts/allowed-hosts, créez-la si nécessaire (mais sachez que le chemin peut être différent sur votre distribution)) pour éviter que le problème ne se reproduise.

— Skippy le Grand Gourou
source

9

Sur le serveur hôte, supprimez la ssh pub.key située ici: ~/.ssh/authorized_keyspour votre mac. Puis, tail -f /var/log/auth.logpendant que vous ouvrez un autre terminal et essayez à nouveau de ssh ssh -v me@server. Si vous êtes invité à entrer un mot de passe, il y a un problème avec votre clé ssh. Si vous voyez toujours la réponse 'ssh_exchange_identification: read: Connexion réinitialisée par un homologue', vous devriez être en mesure d'identifier le problème à partir de l'entrée du journal dans le fichier '/var/log/auth.log' après votre tentative infructueuse. ouvrir une session.

Si vous ne parvenez toujours pas à vous connecter, postez l'entrée journalisée du fichier auth ici et je réviserai ma réponse.

— devnull
source

Pas besoin de supprimer la clé SSH dans certains cas. Allez directement à tail -f /var/log/auth.log et vérifiez les tentatives récentes.

— Jack Robson

6

Cela peut se produire si plusieurs ordinateurs du réseau possèdent la même adresse MAC (par exemple, si vous copiez une machine virtuelle et oubliez de modifier l'adresse MAC).

— El Capitano
source

4

Je recevais cela en raison des serveurs de noms de mon FAI /etc/resolv.conf. Ces serveurs de noms sont souvent surchargés et en cas d'échec de la recherche DNS inversée, sshdla connexion sera interrompue. J'ai résolu le problème en utilisant des serveurs de noms plus fiables, par exemple 8.8.8.8.

— Njahnke
source

4

J'ai été confronté au même problème. Je voudrais ouvrir la session SSH avec succès, mais il serait réinitialisé après un certain temps. Lorsque j’essayais de connecter le gain immédiatement, j’obtenais l’erreur "Connexion refusée". quand j'ai débogué la session j'ai reçu ce message au moment où la connexion était réinitialisée

debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: channel 0: free: client-session, nchannels 1                             
debug3: channel 0: status: The following connections are open:                   
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)                              

debug3: channel 0: close_fds r 4 w 5 e 6 c -1                                    
Read from remote host 10.x.y.z: Connection reset by peer                    
Connection to 10.x.y.z closed.                                              
debug1: Transferred: stdin 0, stdout 0, stderr 100 bytes in 1029.9 seconds       
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1                      
debug1: Exit status -1

À ce stade, j'ai compris qu'il existait un conflit d'adresses IP sur le réseau. J'ai changé d'adresse et le problème a été résolu

— David
source

2

Downvotes, quel est le problème avec la réponse? Il peut toujours être un cas valable à vérifier lorsque vous consultez une liste, mais peut-être pas commune parmi d'autres.

— Pysis

@Pysis: Réponse correcte, plus votée

— Daniel

3

Votre journal signifie que le serveur supprime la connexion. Pour connaître la raison, vous devriez consulter les journaux côté serveur, ils devraient indiquer la raison de la déconnexion. Vous devriez pouvoir presque toujours trouver les journaux dans / var / log / messages

Je pourrais deviner que, comme la connexion a été interrompue juste après le numéro de version envoyé par le client, le serveur menace en quelque sorte le client comme étant incompatible.

— gena2x
source

3

J'ai eu le même problème, mais il s'est avéré que la cause était différente: j'utilisais un mauvais port.

Sur les versions plus récentes de sshl'erreur donnée est Connection refusedou Bad port.

Sur les anciennes versions, l'erreur donnée est ssh_exchange_identification: read: Connection reset by peer

Donc, quand vous obtenez une telle erreur, vérifiez si le port est correct.

— Mugoma J. Okomba
source

1

Je sais que cette question est ancienne, mais je voulais partager certaines de mes conclusions. Vérifiez si /var/empty/sshdle serveur possède la propriété et les autorisations appropriées.

Nous avions un script de chef qui avait été modifié pour mettre à jour certaines autorisations de répertoire, mais nous avions mis à jour par inadvertance le répertoire situé en dessous de la cible visée, en modifiant le droit de propriété de / var sur un utilisateur / groupe d'application et en modifiant les autorisations sur 775.

— Andrew Boerema
source

1

Etant donné que cela n’a pas été explicitement mentionné dans une réponse, cette erreur peut également se produire si un pare-feu réseau entre vous et le serveur a décidé de bloquer la connexion. Le pare-feu aurait pu décider qu'il y avait "trop" de connexions provenant de l'IP du système OS X et a commencé à le bloquer. Il n'y avait pas encore "trop" de connexions de l'autre système, et cela a donc été autorisé.

Le dernier message que vous avez reçu du serveur est celui qui se produit avant même de commencer toute tentative d'authentification, ce qui exclut toute une série de possibilités autour de votre compte, de votre clé ou de votre mot de passe.

Voici des exemples de telles politiques de force brute tirées d'un échantillon aléatoire de fournisseurs:

— Jeff Schaller
source