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


74

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.


donnez s'il vous plaît la sortie de iptables-save|grep -v '^#', cela inclura les autres tables (par exemple natet mangle). S'ils sont vides, dites simplement cela. Votre iptablessortie ci-dessus est par défaut limitée à la filtertable. De plus, sur le serveur SSH, exécutez SSH sur un autre port comme celui-ci et donnez la sortie de débogage.
0xC0000022L

@ 0xC0000022L gist.github.com/Torxed/d7a5a556c527ffbb609d et gist.github.com/Torxed/1fd9b5b0c276629caf30 et en ce qui concerne le pare-feu, SSH travaille pour mon lecteur Windows (encore une fois, même ordinateur portable et adresse IP), mais pas pour mon disque dur.
Torxed

deux autres choses. Vous devez vous connecter à l'instance sur le port alternatif. Sinon, vous ne pourrez pas voir les problèmes possibles. En ce qui concerne Windows et Linux, l’un d’eux utilise-t-il IPv6, peut-être ( ip6tables-save)?
0xC0000022L

@ 0xC0000022L Je suis extrêmement désolé. Je me suis connecté à la mauvaise adresse IP .. Exécution de SSH sur le port 8080, c’est pourquoi j’ai reçu ce problème lors de la connexion à un hôte exécutant un cache Web sur le port 8080> _ <
Torxed

1
Cela m'est arrivé par intermittence alors que mon serveur était attaqué par un attaquant aléatoire qui essayait de forcer sshd par force brutale. Correction en ajoutant des règles de pare-feu pour supprimer les connexions de l'attaquant.
Andrew Hows

Réponses:


61

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.


Je me suis connecté à la mauvaise adresse IP, mais cela m'a permis de continuer. J'ai remarqué qu'aucune de mes tentatives de connexion ne s'est révélée dans la sortie de débogage.
Torxed,

2
$ (quel sshd) -Ddp 10222 me laisse enfin voir ce qui causait mon problème. Merci beaucoup!
Cuga

9

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.


6

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.


10
Si sshdne fonctionnait pas, la connexion ne serait pas fermée mais refusée (essayez ssh -p someportwithoutsshd localhost).
Anthon

4
Eh bien, mon cas n'était pas une connexion directe. J'ai créé un tunnel inverse vers une machine non à l'écoute et c'était la sortie de la connexion du client ssh.
txomon

1
stupide, je ne sais pas non plus que je n'ai pas de sshd en cours d'exécution,
corrigez-

4

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.


20
Comment as-tu fais ça?
Abandonné

4
comment as-tu fais ça? ping ...
knocte

Un moyen serait de trouver les sessions ouvertes en utilisant whoet en tuant les processus utilisateur.
Flatron


4

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

3

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 ???


ls -ld /var/emptyls: cannot access '/var/empty': No such file or directory. Donc, au moins une distribution a complètement éliminé cela. En regardant le /etc/init.d/sshdscript, il semble que sur Debian au moins, le répertoire de séparation des privilèges est maintenant /var/run/sshdet est créé au moment du démarrage s'il n'existe pas déjà.
Roaima

2

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.


1
merci, vous me sauvez la vie.
Al Kasih

0

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).


2
Dans ce cas, vous obtiendrez une «connexion refusée», comme le ferait une autre réponse implicite , et non pas «Connexion établie» suivie de «Connexion réinitialisée par un pair»
Jeff Schaller

1
Avoir telnet disponible (le démon écoutant telnet) est une faille de sécurité assez grave, une faille qui est la raison principale pour laquelle ssh est la console distante préférée.
Xalorous

L'utilisation du client telnet pour sonder le démon ssh sur le port 22 n'est pas une faille de sécurité. L'utilisation du client telnet pour se connecter au démon telnet sur le port 23 est une faille de sécurité.
Dan Anderson

0

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.


0

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


0

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

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.