Erreur de tunnel ssh «ssh_exchange_identification: connexion fermée par l'hôte distant»

10

J'essaie d'utiliser un tunnel ssh de mon ordinateur de bureau à mon ordinateur personnel et j'obtiens une erreur lorsque j'essaie de l'utiliser.

Ce que je fais, c'est démarrer un shell comme ceci:

ssh -gL 12345:my.home.domain:22 my.home.domain

Cela me donne une bonne coque, pas de problème. Ce que je fais normalement ensuite est ssh vers ma machine à domicile via cette machine de bureau, comme ceci:

ssh -p 12345 127.0.0.1

Cela a toujours fonctionné pour moi, jusqu'à la semaine dernière, lorsque j'ai mis en place un nouveau système sur ma machine domestique (passage d'Ubuntu à Debian). Maintenant, je reçois une erreur. Je peux toujours ouvrir ma connexion ssh initiale, mais lorsque j'essaie d'utiliser ce tunnel, j'obtiens (sur la machine de bureau) cette erreur:

ssh_exchange_identification: Connection closed by remote host

De plus, lorsque cela se produit, le shell ouvert sur lequel j'ai configuré le tunnelage obtient cette ligne crachée:

channel 3: open failed: connect failed: Connection timed out

À ce stade, je suis perdu. Si plus d'informations sont nécessaires, je serai heureux de les publier.

============= suite à cela ==============

Après avoir tripoté plus loin, j'ai constaté que j'obtiens une réponse différente du serveur (ma machine domestique qui est) lorsque j'essaie de me connecter via Telnet sur les différents ports. Si j'essaye:

telnet my.home.domain 22

Je récupère ceci:

Trying <my ip address>...
Connected to <my domain>.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze2

C'est ce à quoi je m'attendrais. Après avoir mis en place le tunnel, puis en téléphonant à cela, je vois cette réponse:

Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.

============== et plus encore ==================

Selon la suggestion de kbulgrien , voici la sortie de la machine cliente avec l'option -v:

ssh -vp 24600 127.0.0.1
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 mars 2012
debug1: lecture des données de configuration / etc / ssh / ssh_config
debug1: / etc / ssh / ssh_config ligne 19: Application d'options pour *
debug1: Connexion au port 24600 127.0.0.1 [127.0.0.1].
debug1: connexion établie.
debug1: fichier d'identité /home/jacob/.ssh/id_rsa type -1
debug1: fichier d'identité /home/jacob/.ssh/id_rsa-cert type -1
debug1: fichier d'identité /home/jacob/.ssh/id_dsa type -1
debug1: fichier d'identité /home/jacob/.ssh/id_dsa-cert type -1
debug1: fichier d'identité /home/jacob/.ssh/id_ecdsa type -1
debug1: fichier d'identité /home/jacob/.ssh/id_ecdsa-cert type -1
ssh_exchange_identification: Connexion fermée par l'hôte distant

ssh-tunnel

— Jacob Ewing
source

L'une des causes de l' ssh_exchange_identification: Connection closed by remote hosterreur est liée à l'hôte de connexion répertorié dans le /etc/hosts.deny.

— Zoredache

Hm - si je cat /ets/hosts.deny sur cette machine, chaque ligne est remarquée.

— Jacob Ewing

Puis-je suggérer d'ajouter -và la commande ssh qui échoue? La sortie qui suit donne-t-elle une autre indication d'échec (c. channel 1: open failed: administratively prohibited: open failed-à-d.).

— kbulgrien

2

Désolé, il m'est juste venu à l'esprit qu'il est utile d'avoir -và la fois le tunnel et les commandes ssh défaillantes (à la recherche de quelque chose de plus channel 3: open failed: connect failed: Connection timed out). Il pourrait être intéressant de mentionner que l'on peut ajouter plusieurs -v(jusqu'à trois) pour augmenter la verbosité. Je ne publierais pas nécessairement tout le discours, mais il pourrait être utile de parcourir les mots qui semblent indiquer un problème.

— kbulgrien

1

Peut-être que si vous avez plus de 10 sessions ssh en attente d'insertion du mot de passe, vous avez ce genre d'erreur, je me souviens que c'était un bug ssh récent, si vous voulez le vérifier, utilisez la commande ci-dessous

for i in {1..15};do ssh -fNt pippo@remote.server.com & >/dev/null ;done

— c4f4t0r
source

0

Quelque chose comme ça s'est produit lors d'une récente installation. Dans cette situation /etc/hosts.deny existait et n'avait pas de paramètres qui explicitement refusaient l'accès, donc les circonstances semblent similaires. Il était nécessaire de modifier /etc/hosts.allow pour ajouter quelque chose comme:

sshd: 192.168.127.0/255.255.255.128

Les détails IP doivent être ajustés à vos besoins ou remplacés par ALLs'il n'y a aucun souci à autoriser ssh de partout.

Après avoir apporté les modifications, arrêtez et redémarrez sshd.

Les réponses votées à la question suivante fournissent plus d'exemples.

SSH hosts.deny et hosts.allow

Voici le témoignage de quelqu'un d'autre qui relie le message d'erreur à la solution.

Résolution des problèmes: ssh_exchange_identification: connexion fermée par un problème d'hôte distant lors de la connexion avec SSH

— kbulgrien
source

Hmm - malheureusement, cela n'a pas réglé le problème pour moi. Je pense que ma situation diffère de celles de l'exemple. Je suis capable de ssh sur le port 22 sans problème. Ce n'est que lorsque j'essaie de passer par un autre port que j'obtiens les erreurs mentionnées.

— Jacob Ewing

Certes, le tunnel est une différence distinctive. Cela étant, cela aide-t-il: discussion.dreamhost.com/thread-97951.html ? J'ai également trouvé des références à une indication selon laquelle la désinstallation et la réinstallation du paquet sshd sur des systèmes de type Debian corrige un problème avec les clés qui provoque le comportement que vous décrivez ( discussion.dreamhost.com/thread-97951.html et. Al.) .

— kbulgrien

Vous avez installé sshd (openssh-server) sur les deux systèmes, non?

— kbulgrien

Ouaip. Je fais cela depuis assez longtemps et je n'ai rencontré des problèmes que la semaine dernière après être passé à Debian sur ma machine domestique (le serveur). J'essaierai votre suggestion de désinstaller / réinstaller sshd quand je rentrerai ce soir.

— Jacob Ewing

0

J'ai eu le même problème et j'ai finalement résolu le problème en corrigeant /etc/network/interfaces:

auto eth0
iface eth0 inet static

ou

auto eth0
iface eth0 inet dhcp

sans cette configuration, je ne reçois jamais de connexion inverse à mon tunnel ssh.

— dr4ck0
source

0

Dans mon cas, j'ai dû insérer dans /etc/ssh/sshd_configla machine passerelle les lignes suivantes:

Match User <username>
   GatewayPorts yes

Voir plus de détails ici

J'espère que cela t'aides!

— flottant
source