ssh_exchange_identification: Connexion fermée par l'hôte distant (n'utilisant pas hosts.deny)
Je suis pas en utilisant hosts.allow ou hosts.deny, de plus SSH fonctionne depuis ma machine Windows (même ordinateur portable, disque dur différent) mais pas ma machine Linux.
ssh -vvv root@Host -p port donne:
OpenSSH_6.6, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to Host [Host] port <port>.
debug1: Connection established.
debug1: identity file /home/torxed/.ssh/id_dsa type -1
debug1: identity file /home/torxed/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6
ssh_exchange_identification: read: Connection reset by peer
Sur la machine Windows, tout fonctionne bien, j'ai donc vérifié les journaux de sécurité et les lignes qui s'y trouvent sont identiques, le serveur ne traite pas les deux "machines" différentes et elles sont toutes les deux autorisées via l'authentification par clé publique.
Cela conduit donc à la conclusion que cela doit être un problème avec mon ordinateur portable local ArchLinux .. mais quoi?
[torxed@archie ~]$ cat .ssh/known_hosts
[torxed@archie ~]$
Ce n'est donc pas le problème ..
[torxed@archie ~]$ Sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Pas de conflits avec les paramètres du pare-feu (pour l'instant) ..
[torxed@archie ~]$ ls -la .ssh/
total 20
drwx------ 2 torxed users 4096 Sep 3 2013 .
drwx------ 51 torxed users 4096 May 11 11:11 ..
-rw------- 1 torxed users 1679 Sep 3 2013 id_rsa
-rw-r--r-- 1 torxed users 403 Sep 3 2013 id_rsa.pub
-rw-r--r-- 1 torxed users 170 May 11 11:21 known_hosts
Les autorisations semblent bien (même chose sur le serveur) .. Également essayé sans configurer /etc/ssh/ssh_config avec le même résultat sauf pour beaucoup de configuration automatique en cours dans le client qui se termine avec la même erreur.
Publié à l'origine sur Ask Ubunt
Si vous avez exclu tout facteur "externe", l'ensemble des étapes suivantes aide généralement à le réduire. Donc, même si cela ne répond pas directement à votre question, cela peut aider à rechercher la cause de l'erreur.
Dépannage sshd
Ce que je trouve généralement très utile dans de tels cas est de démarrer sshd sans le laisser démoniser. Le problème dans mon cas était que ni syslog ni auth.log Ne montraient quoi que ce soit de significatif.
Quand je l'ai démarré depuis le terminal, j'ai eu:
# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.
Bien mieux! Ce message d'erreur m'a permis de voir ce qui ne va pas et de le corriger. Aucun des fichiers journaux ne contenait cette sortie.
NB: au moins sur Ubuntu la $(which sshd) est la meilleure méthode pour satisfaire sshd l'exigence d'un chemin absolu. Sinon, vous obtiendrez l'erreur suivante: sshd re-exec requires execution with an absolute path. Le -p 10222 Permet à sshd d'écouter sur ce port alternatif, en remplaçant le fichier de configuration - afin qu'il n'entre pas en conflit avec les instances sshd potentiellement en cours d'exécution. Assurez-vous de choisir un port gratuit ici.
Enfin: connectez-vous au port alternatif (ssh -p 10222 user@server).
Cette méthode m'a aidé plusieurs fois à trouver des problèmes, que ce soit des problèmes d'authentification ou d'autres types. Pour obtenir une sortie vraiment verbeuse vers stdout, utilisez $(which sshd) -Ddddp 10222 (notez le dd ajouté pour augmenter la verbosité). Pour plus d'informations sur le débogage, vérifiez man sshd.
Le principal avantage de cette méthode est qu'elle permet de vérifier la configuration de sshd sans de devoir redémarrer sshd sur le port par défaut. Normalement cela ne devrait pas interférer avec les connexions SSH existantes, mais je l'ai vu. Cela permet donc de valider le fichier de configuration avant - potentiellement - de couper l'accès à un serveur distant (par exemple, je l'ai pour certains VPS et même pour les serveurs physiques où je dois payer un supplément pour obtenir un accès hors bande à la machine).
Vous pouvez également avoir un hôte dont la mémoire est si gravement fragmentée qu'il ne peut pas allouer à une page une mémoire contiguë pour bifurquer le processus d'hébergement d'une session SSH.
Dans un tel cas, vous pouvez obtenir l'un des messages:
ssh_exchange_identification: read: Connection reset by peer
ou:
Connection closed by aaa.bbb.ccc.ddd
en fonction de la distance parcourue par l'hôte avant de sortir.
Si la fragmentation de la mémoire en est la cause apparente, la solution consiste à accéder au serveur par d'autres moyens et à redémarrer certains des services pertinents. J'ai trouvé Apache et MySQL pour être le coupable sur les VM depuis que les VM n'ont pas de partition de swap. À défaut, redémarrez l'hôte.
Juste au cas où, parce que cela m'est arrivé. Assurez-vous que sshd fonctionne sur l'hôte!
C'est un échec stupide, mais cela pourrait être vraiment votre problème.
J'ai trouvé que cette erreur était due au dépassement des sessions ssh sur le serveur. J'ai trouvé les hôtes essayant de se connecter et a tué toutes les sessions de tous les clients. Le problème a été résolu après avoir nettoyé toutes les sessions.
J'ai couru à travers le ssh_exchange_identification: read: Connection reset by peer problème dans un script qui démarre 16 sessions ssh ou plus en boucle. sshd ne peut apparemment pas suivre; l'ajout d'un court sommeil a résolu mon problème:
for i in $(seq 32)
do
ssh -f root@$Host "./test_server -p $(expr $BASE_PORT + $i)" > svr${i}.out
# for > 8 connections, ssh has ssh_exchange_identification issues
sleep 0.1
done
J'ai eu l'erreur ssh_exchange_identification: Connection closed by remote Host lorsque j'essaie de me connecter à SSH: j'ai effectué un transfert de port distant pour le port SSH 22 de mon ordinateur local afin de pouvoir y accéder temporairement à partir d'un serveur distant sur Internet.
En fait, l'erreur vient de s'afficher car je ne me souvenais pas d'avoir désactivé le service SSH au démarrage, j'ai donc dû démarrer le service SSH sur mon ordinateur local: Sudo service ssh start.
Ou vous avez peut-être fait ce que j'ai fait hier soir et supprimé/var/empty. Apparemment, ce répertoire et ses autorisations sont essentiels au fonctionnement de sshd et il ne refera pas le répertoire au redémarrage /etc/init.d/sshd ne redémarrera pas et rien dans systemd ne vous expliquera pourquoi.
J'ai trouvé le problème en exécutant sshd au premier plan:
# /usr/sbin/sshd -Dd
Missing privilege separation directory: /var/empty/sshd
La reconstruction des répertoires a résolu le problème dans mon cas:
drwxr-xr-x. root root /var/empty
drwx--x--x. root root /var/empty/sshd
Remarque pour les programmeurs Linux: des informations importantes dans /var/empty ... vraiment???
Commençons par le commencement; telnet à l'adresse IP de l'hôte pour vérifier si le port 22 écoute réellement (ouvert) sur cet hôte:
telnet x.x.x.x 22
(sinon, vous pouvez brancher un câble de console pour vous connecter)
Dans mon cas, cela ne fonctionnait pas et j'ai branché un câble de console pour me connecter. Une fois connecté, j'ai découvert que les 5 lignes VTY étaient occupées sur cet hôte (un routeur Cisco).
J'ai effacé les anciennes connexions qui étaient suspendues pour libérer les lignes VTY, cela a fonctionné. J'ai ajouté la commande "exec-timeout 15" sous les lignes VTY. J'ai ensuite retiré le câble de la console.
Leçon:
Assurez-vous de définir un délai d'expiration de 5 à 10 minutes sur tous vos appareils - (si aucune activité n'est détectée).
Mon cas a été défini par erreur comme un proxy de socket (qui ne fonctionne pas). J'ai exactement la même sortie ssh -vvv et le journal sshd vide.
J'obtenais une erreur similaire en essayant de ssh avec l'utilisateur root, dans un conteneur récemment créé:
ssh root@localhost -p 8022
ssh_exchange_identification: Connection closed by remote Host
# local port 8022 is redirected to container ssh port 22
Apparemment, cela s'est produit depuis le tilisateur ("root" dans mon cas) n'avait pas de mot de passe.
Une fois que j'ai ajouté le mot de passe de l'utilisateur et redémarré sshd (à l'intérieur du conteneur):
echo 'root:<PASSWORD>' | Sudo chpasswd
Sudo service ssh restart
Ensuite, je pouvais ssh dans le conteneur.
De avec CentOS Linux release 7.4.1708 (Core) avec OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017 derrière une connexion ne filtrant pas les ports que j'avais:
ssh_exchange_identification: Connexion fermée par l'hôte distant
Et il s'est avéré que mon Raspberry Pi était éteint!
Je pensais qu'un hôte non allumé aurait généré l'erreur "Pas de route vers l'hôte". Le Raspberry Pi est derrière mon routeur ISP donc c'est probablement lui qui fermait la connexion.
Ensuite, j'ai répété l'expérience (tentative de connexion à un Raspberry Pi éteint) à partir d'une autre connexion Internet, sans filtrage des ports avec Debian Stretch avec OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017 et cette fois j'ai eu les attentes:
Aucune route vers l'hôte
L'erreur ssh_exchange_identification: Connection closed by remote Host peut se produire pour des raisons inconnues. Quand j'utilisais code Visual Studio. La même erreur s'est produite lorsque j'ai essayé de retirer du référentiel distant en utilisant git pull commande.
J'ai juste fermé le terminal intégré et ouvert le terminal d'Ubuntu et tiré à nouveau. Et ça a réussi