Erreur de connexion SSH: ssh_exchange_identification: lecture: connexion réinitialisée par l'homologue


25

Lorsque j'ai essayé de me connecter au serveur via SSH, j'obtiens l'erreur suivante,

[root@oneeighty ~]# ssh -vvv -p 443 root@xxx.xxx.xxx
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xxx.xxx.xxx [IP] port 443.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: loaded 3 keys
ssh_exchange_identification: read: Connection reset by peer

J'ai vérifié la configuration SSH sur le serveur et le client et il n'y a aucun problème.

Redémarrez le service SSH sur le serveur, puis redémarrez le serveur / client, mais les problèmes ne sont pas résolus.


Vous pouvez autoriser la connexion ssh par l'interface utilisateur du pare-feu (certains fournisseurs le permettent) ou si vous avez une autre méthode pour vous connecter (par exemple, digitalocean fournit un bouton de console), vous pouvez exécuter la commande sudo ufw allow ssh sudo ufw allow 22
BSB

Réponses:


26

Cela peut être le résultat d'un certain nombre de choses.

Peu de choses que vous pouvez essayer rapidement sont les suivantes,

  • Regardez dans /etc/hosts.deny pour toute entrée comme sshd: ALL
  • Peut-être, ajouter sshd: ALLà/etc/hosts.allow

  • Il est possible que les HostKeys de votre SSHD soient corrompus. Ils sont présents dans le répertoire / etc / ssh /. Vous pouvez les supprimer et redémarrer sshd et il les régénérera. En cas d'erreur, veuillez utiliser les commandes suivantes

    $ ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
    $ ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
    $ ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key
    $ /etc/init.d/sshd start
    

sur /etc/hosts.deny et /etc/hosts.allow, toutes les lignes sont commentées.
Senthil G

1
Veuillez ajouter sshd: ALLà hosts.deny pour vérifier si cela aide.
vagarwal

2

La ligne suivante du débogage devrait ressembler à ceci:

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3ubuntu7

Vous avez confirmé sur StackOverflow que vous utilisez NATing / redirection de port à partir d'une adresse IP externe. Vous avez également vérifié que vous pouvez ssh de la boîte locale à lui-même. Comme le fonctionnement local du port 443 fonctionne, vous devez vérifier que le mappage de port fonctionne.

Essayer:

  1. SSH d'une autre boîte dans le même sous-réseau
  2. Exécutez iptables -Let vérifiez que le port 443 est ouvert ou INPUT et OUTPUT est réglé sur ACCEPT
  3. Exécutez tcpdump -A -s 0 port 443, puis essayez de sshing vers l'IP externe. Vous devriez voir les données arriver avec l'adresse source du routeur

2

FWIW, j'utilise Ubuntu 14.04 sur AWS. Le problème a été résolu par SSHing via leur client Web Java et en cours d'exécution sudo service apache2 start. Je voulais juste que mon site Web soit sauvegardé, mais cela a également corrigé l'accès SSH. Je ne sais pas pourquoi, mais je ne me plains pas.


même problème ici. ma session n'a pas répondu sans raison et je n'ai pas pu me reconnecter via le mastic. l'utilisation du client Web a fait tout ce qui était magique pour permettre à ma connexion via le mastic de fonctionner à nouveau.
AndrewK

Merci, je ne sais pas comment mais ça a vraiment aidé. *** aws
Siarhey Uchukhlebau

1

Vérifiez les hôtes autorisés sur le serveur auquel vous essayez de vous connecter, ainsi que toutes les règles iptables qu'il exécute.


1

Le problème a été résolu.
Le problème concerne les équilibreurs de charge que nous avons sur notre réseau. Le problème est résolu au redémarrage des équilibreurs de charge.


1

J'ai rencontré un problème similaire aujourd'hui, car soudainement l'accès ssh à une machine virtuelle a été refusé avec le même message. ssh -v (au client) et sshd -d (au serveur) n'ont pas beaucoup aidé. Le problème dans mon cas a commencé en raison de la modification des paramètres du pare-feu / iptable, ce que j'ai fait pour une démonstration de l'utilisation de la pile LAMP.

J'ai utilisé system-config-firewall-tui pour activer le pare-feu et sélectionné uniquement httpd à partir de là, ce qui a bloqué tous les autres services sauf httpd.

Donc, comme solution à cela, ajoutez des autorisations à sshd en

  • mise à jour des paramètres de conf iptable OU
  • Sélection de sshd dans system-config-firewall-tui OU
  • Désactiver le pare-feu OU
  • Arrêtez le service iptable (rhel6, supprimez-le également de chkconfig)

ssh fonctionne parfaitement bien maintenant !!!


0

Pour moi, j'autorise les connexions sshd dans le fichier / etc / hosts.

vi /etc/hosts.allow
and add 

sshd: ALL

0

La façon dont j'ai résolu le problème est que je suis allé sur la machine hôte et que j'ai exécuté quelques commandes

sudo mkdir / var / run / sshd

sudo chmod 755 -R / var / run / sshd

sudo service ssh restart

Je me suis connecté à la machine après ça.


-3

Première purge openssh- * (openssh-server et openssh-client)

apt-get --purge remove openssh-*

suppression du répertoire /home/username/.ssh

rm -rf /home/username/.ssh 

puis installez votre serveur openssh et votre client openssh

apt-get install openssh-server openssh-client

3
Non, même pas proche, la réponse du PO dit quel était le problème. Vous répondez est spécifique aux distributions qui utilisent apt, l'OP utilisait RHEL. Supprimer et réinstaller un package n'est presque jamais la solution.
user9517 prend en charge GoFundMonica

Avez-vous fait tout cela sur le serveur local ou distant?
Jonathan
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.