ssh_exchange_identification: Connexion fermée par l'hôte distant (n'utilise pas hosts.deny)

Je n'utilise pashosts.allow ou hosts.deny, plus encore, SSH fonctionne à partir de ma machine Windows (même ordinateur portable, disque dur différent), mais pas de 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 correctement, alors j'ai vérifié les journaux de sécurité et les lignes qui y sont identiques, le serveur ne traite pas les deux "machines" différentes et elles sont toutes deux autorisées via une authentification à clé publique.

Cela mène donc à la conclusion que cela doit être un problème avec mon ordinateur portable ArchLinux local .. mais quoi?

[torxed@archie ~]$ cat .ssh/known_hosts 
[torxed@archie ~]$ 

Donc ce n'est 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 conflit 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 être correctes (identique sur le serveur). Également essayé sans configuration /etc/ssh/ssh_configavec le même résultat, à l'exception d'un grand nombre de configurations automatiques en cours dans le client qui aboutissent à la même erreur.

Si vous avez exclu des facteurs "externes", les étapes suivantes permettent généralement de les réduire. Ainsi, même si cela ne répond pas directement à votre question, cela peut aider à identifier la cause de l'erreur.

Dépannage sshd

Ce que je trouve généralement très utile dans de tels cas est de commencer sshdsans le démoniser. Le problème dans mon cas était que ni rien montré syslogni auth.logsignificatif.

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.

Beaucoup mieux! Ce message d'erreur m'a permis de voir ce qui n'allait pas et de le réparer. Aucun des fichiers journaux ne contenait cette sortie.

NB: du moins sur Ubuntu, $(which sshd)c’est la meilleure méthode pour satisfaire l’ sshdexigence d’un chemin absolu. Sinon , vous aurez l'erreur suivante: sshd re-exec requires execution with an absolute path. Le -p 10222fait d' sshdécouter sur ce port alternatif, en surchargeant le fichier de configuration - afin d'éviter tout conflit avec des sshdinstances potentiellement en cours d'exécution . Assurez-vous de choisir un port libre ici.

Enfin: connectez-vous au port alternatif ( ssh -p 10222 user@server).

Cette méthode m'a souvent aidé à trouver des problèmes, que ce soit des problèmes d'authentification ou d'autres types. Pour obtenir une sortie vraiment verbeuse stdout, utilisez $(which sshd) -Ddddp 10222(notez la valeur ajoutée ddpour augmenter la verbosité). Pour plus de vérification de la qualité de débogage man sshd.

Vous pouvez également avoir un hôte dont la mémoire est tellement fragmentée qu'elle ne peut pas allouer une page à une mémoire contiguë pour créer le processus d'hébergement d'une session SSH.

Dans un tel cas, vous pouvez recevoir l'un des messages suivants:

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 s'en sortir.

Si la fragmentation de la mémoire 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 comme coupables sur les ordinateurs virtuels, ceux-ci n'ayant pas de partition d'échange. À défaut, redémarrez l'hôte.

Juste au cas où, parce que cela m'est arrivé. Assurez-vous que sshd tourne dans l'hôte!

C'est un échec stupide, mais pourrait être vraiment votre problème.

J'ai trouvé que cette erreur était due au dépassement du nombre de sessions SSH sur le serveur. J'ai trouvé les hôtes essayant de se connecter et tué toutes les sessions de tous les clients. Le problème est résolu après le nettoyage de toutes les sessions.

J'ai rencontré le ssh_exchange_identification: read: Connection reset by peerproblème dans un script qui démarre 16 sessions SSH ou plus en boucle. sshd ne peut apparemment pas suivre; ajouter 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

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 sera pas refait lorsqu'il /etc/init.d/sshdsera redémarré au redémarrage ne pourra pas redémarrer et rien ne vous dira 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

Note aux programmeurs Linux: Des choses extrêmement importantes dans /var/empty... vraiment ???

J'ai eu l'erreur ssh_exchange_identification: Connection closed by remote hosten essayant de me connecter à SSH: j'ai fait un transfert de port distant pour le port SSH 22 de mon ordinateur local afin que je puisse y accéder temporairement à partir d'un serveur distant sur Internet.

En fait , l'erreur vient d'être affichée parce que je ne me souviens pas que je désactiver le service SSH au démarrage si je devais démarrer le service SSH sur mon ordinateur local: sudo service ssh start.

Commençons par le commencement; telnet à l'adresse IP de l'hôte pour vérifier si le port 22 est réellement à l'écoute (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. Puis j'ai enlevé le câble de la console.

Leçon:

Veillez à 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 proxy de socket (qui ne fonctionne pas). J'ai exactement le même résultat ssh -vvv et le journal sshd vide.

L'erreur ssh_exchange_identification: Connection closed by remote hostpeut arriver pour des raisons inconnues. Quand j'utilisais le code Visual Studio . La même erreur s’est produite lorsque j’ai essayé d’extraire du dépôt à distance en utilisant la git pullcommande.

Je viens de fermer le terminal intégré , d' ouvrir le terminal d'Ubuntu et de tirer à nouveau. Et c'était réussi

De avec CentOS Linux release 7.4.1708 (Core)avec OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017derrière une connexion ne filtrant pas les ports 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 "Aucune route à héberger". Le Raspberry Pi est derrière mon routeur ISP, donc c'est probablement ce 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, ne filtrant pas non plus les ports avec Debian Stretch OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017et cette fois, j'avais l'attendu:

Pas de route à héberger