tunnel ssh refusant les connexions avec “channel 2: open failed”

71

Tout à coup (lire: sans changer aucun paramètre), ma machine virtuelle netbsd a commencé à agir étrangement. Les symptômes concernent ssh tunneling.

Depuis mon ordinateur portable je lance:

$ ssh -L 7000:localhost:7000 user@host -N -v

Ensuite, dans un autre shell:

$ irssi -c localhost -p 7000

Le débogage ssh dit:

debug1: Connection to port 7000 forwarding to localhost port 7000 requested.
debug1: channel 2: new [direct-tcpip]
channel 2: open failed: connect failed: Connection refused
debug1: channel 2: free: direct-tcpip: listening port 7000 for localhost port 7000, connect from 127.0.0.1 port 53954, nchannels 3

J'ai aussi essayé avec localhost: 80 de me connecter au serveur Web (distant), avec des résultats identiques.

L’hôte distant exécute NetBSD:

bash-4.2# uname -a
NetBSD host 5.1_STABLE NetBSD 5.1_STABLE (XEN3PAE_DOMU) #6: Fri Nov  4 16:56:31 MET 2011  root@youll-thank-me-later:/m/obj/m/src/sys/arch/i386/compile/XEN3PAE_DOMU i386

Je suis un peu perdu. J'ai essayé de courir tcpdumpsur l'hôte distant, et j'ai repéré ces 'bad chksum':

09:25:55.823849 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 67, bad cksum 0 (->3cb3)!) 127.0.0.1.54381 > 127.0.0.1.7000: P, cksum 0xfe37 (incorrect (-> 0xa801), 1622402406:1622402421(15) ack 1635127887 win 4096 <nop,nop,timestamp 5002727 5002603>

J'ai essayé de redémarrer le démon ssh en vain. Je n'ai pas encore redémarré - peut-être que quelqu'un ici peut suggérer d'autres diagnostics. Je pense que cela peut être soit le pilote de la carte réseau virtuelle, ou quelqu'un qui a enraciné notre ssh.

Des idées ..?

— lorenzog
source

1

Pour le dépannage, essayez $ ssh -L 7000:127.0.0.1:7000 user@host -N -v -v. (Vous pouvez utiliser "-v" jusqu'à 3 fois pour augmenter la verbosité.) Aussi, est-il possible que ssh ait été récemment mis à jour?

— Mike Sherrill 'Cat Recall'

Le journal de sortie que j'ai collé était déjà rassemblé avec -v.

— Lorenzog

1

Vous pouvez utiliser -v jusqu'à trois fois pour augmenter la verbosité. Donc, vous pouvez regarder la sortie de ssh -L 7000... -N -v -v(deux v) ou ssh -L 7000... -N -v -v -v.

— Mike Sherrill 'Cat Recall'

@ MikeSherrill'CatRecall 'Un raccourci peut également être utilisé: -vvv

— jnns

42

Problème résolu:

$ ssh -L 7000:127.0.0.1:7000 user@host -N -v -v

... apparemment, l'hôte distant n'aime pas « localhost ». Pourtant, la télécommande /etc/hostscontient:

::1                     localhost localhost.
127.0.0.1               localhost localhost.

tandis que l'interface du réseau local est

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33184
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2

Soupir. tant pis pour la prime de 100 rp que j'ai mise :)

— lorenzog
source

1

Ah Eh bien, je ne prendrai pas la peine d’écrire mon commentaire comme réponse. (Vérifiez si ssh préfère les adresses ipv6 sur votre système.)

— Mike Sherrill 'Cat Recall'

Eh bien, vous avez suggéré de doubler l’option -v, mais cela n’a rien montré de nouveau. Cependant, en me faisant revoir la sortie au bout de quelques jours, cela a permis de mieux cerner le problème. Si vous voulez écrire la réponse, je suis ravi de vous donner la prime.

— Lorenzog

1

En réalité, l’important était de remplacer "localhost" par "127.0.0.1". Les arguments "-v" supplémentaires auraient peut-être été utiles, mais ils ne correspondaient pas à ce que je cherchais. Merci.

— Mike Sherrill 'Cat Recall' le

selon ce post sur superutilisateur: superuser.com/questions/346971/ssh-tunnel-connection-refused - un programme configuré pour écouter une adresse spécifique écoutera cette adresse spécifique

— jopasserat

1

Pour moi, ajouter le préfixe ":" fonctionne si bien que la commande dans votre cas ressemblerait à ceci: ssh -L: 7000: 127.0.0.1: 7000 utilisateur @ hôte -N -v -v

— valentt

21

Bien que le problème d'OP ait déjà été résolu, j'ai décidé de partager la solution à mon problème, car j'ai reçu le même message d'erreur de ssh et je n'ai trouvé aucune solution sur d'autres sites.

Dans mon cas, je devais me connecter au service qui n'écoute que sur IPv6. J'ai essayé:

ssh -f root@192.168.0.18 -L 51005: 127.0.0.1: 51005 -N
ssh -f root@192.168.0.18 -L 51005: hôte local: 51005 -N

et quelques autres moyens mais cela n'a pas fonctionné. Toute tentative de connexion http://localhost:51005entraîne des erreurs comme celle-ci: channel 2: open failed: connect failed: Connection refused

La solution est:

ssh -f root@192.168.0.18 -L 51005: [:: 1]: 51005 -N

L'adresse IPv6 doit être entre crochets.

— rzymek
source

1

Que faire si vous utilisez un fichier de configuration ssh? exemple: "LocalForward localhost: 64160 192.168.1.56:3389"

— meffect

Pour moi, ajouter le préfixe ":" fonctionne si bien que, dans votre cas, la commande ressemblerait à ceci: ssh -f root@192.168.0.18 -L: 51005: 127.0.0.1: 51005 -N

— valentt le

9

Je voudrais d'abord essayer ceci.

$ ssh -L 7000:127.0.0.1:7000 user@host -N -v -v

Vous pouvez utiliser "-v" jusqu'à 3 fois pour augmenter la verbosité.

Je pense que ce message d'erreur peut survenir si un pare-feu bloque le port 7000, mais vous l'aviez déjà décidé. (Si les lecteurs ultérieurs ne l'ont pas exclu, regardez le résultat de netstat --numeric-ports.)

Je pense que j'ai peut-être vu ce message d'erreur il y a longtemps, lorsque ssh a découvert pour la première fois les adresses IPV6 à la suite d'une mise à jour. Je peux me tromper à ce sujet. Si vous avez envie d'expérimenter, vous pouvez essayer l'adresse de bouclage IPV6 "0: 0: 0: 0: 0: 0: 0: 1" (ou ":: 1").

— Mike Sherrill 'Rappel de chat'
source

3

"... apparemment, l'hôte distant n'aime pas 'localhost'. Pourtant, le fichier / etc / hosts distant contient:"

Sauf que vous utilisiez ssh sur le client, votre client n'aimait donc pas 'localhost'. Le fichier / etc / hosts distant est destiné à la connexion distante , pas aux connexions entrantes .

— bilbo baggins
source

1

c'était aussi déroutant pour moi. Lorsque vous tapez localhost dans votre machine locale, le problème est résolu localement

— Ahmedov le

3

J'ai rencontré cette même erreur en essayant de se connecter à mysql sur un autre serveur via un tunnel ssh. J'ai constaté que le paramètre bind-address dans /etc/my.cnf sur le serveur cible était lié à mon adresse IP externe (serveur à deux cartes réseau) plutôt qu'à interne, ce qui ne m'était d'aucune utilité.

Lorsque j'ai défini bind-address = 127.0.0.1, je pouvais utiliser mon tunnel ssh comme suit:

ssh -N -f -L 3307:127.0.0.1:3306 user@server.name

mysql -h 127.0.0.1 --port=3307 --protocol=TCP -uusername -ppassword

— Tom McQuarrie
source

Cela a fonctionné pour moi aussi. Vous ne pouvez lier MySQL qu’à une seule adresse.

— leeand00

3

J'ai rencontré cette erreur lorsque je transmettais des ports avec un nom de domaine complet au lieu de localhost:

ssh -L 5900:host.name.com:5900 x11vnc

Le port était ouvert uniquement pour localhost. Pour accepter des connexions avec un nom complet, je devais donc ajouter une description du port de liaison :

ssh -L *:5900:host.name.com:5900 x11vnc

ce qui permettrait des connexions de n'importe où (donc ce n'est pas si sûr, utilisez-le avec parcimonie).

— cengique
source

2

Pour moi, ajouter le préfixe ":" fonctionne si bien que la commande dans votre cas ressemblerait à ceci:

ssh -L :7000:localhost:7000 user@host -N -v

— valentt
source

Trop de temps a passé et je ne peux plus revenir en arrière, mais ça a l'air génial.

— lorenzog

1

???

canal 2: échec de l'ouverture: échec de la connexion: connexion refusée

Sur user@hostle port d’écoute 7000, rien de plus simple.

— poige
source

1

Ce n'est pas vrai. Un service est exécuté sur l'hôte: 7000. J'ai aussi essayé avec d'autres services.

— Lorenzog

2

Non, alors il se bloque juste la connexion.

— RickyA

4

@ RickyA: En fait, ce n'est pas vrai. Si le port n'est pas lié, la connexion sera refusée. J'ai eu cette erreur en utilisant le mauvais port interne (où aucun service ne fonctionnait), l'erreur a disparu lorsque j'ai corrigé l'erreur. poige a raison de dire que si rien n’écoute sur le port, l’erreur sera causée.

— erb

1

J'ai reçu le même message d'erreur:

canal 3: échec de l'ouverture: échec de la connexion: connexion refusée

Et la cause était une erreur humaine - moi essayant d'accéder à un port différent sur l'hôte distant que celui que j'ai spécifié.

Je pensais que je partagerais cela, bien que ce ne soit probablement pas la raison pour laquelle la plupart d’entre vous rencontrez cette erreur.

— Roe Bahumi
source

Dans mon cas: c'est exactement ce que je faisais. Une telle erreur stupide mais il a fallu cette réponse pour me faire vérifier le port. Doh.

— Ken Sharp

1

Pour moi, j'essayais ssh -L <port>:<remote server IP>:<port> <login>@<remote server IP>quand j'aurais dû le faire ssh -L <port>:127.0.0.1:<port> <login>@<remote server IP>.

J'espère que ça aidera quelqu'un!

— ryanwc
source

1

Une interprétation alternative est, dans mon cas, votre frappe est incorrecte.

user@host ~ $ ssh -vvvNL 4444:127.0.0.0.1:4444
...
channel 2: open failed: connect failed: Name or service not known

Qu'est-ce qui se passe ici est que l'adresse IP a un trop de zéros, donc pas une adresse valide. Donc ssh le traite plutôt comme un nom de domaine qu’il ne peut pas résoudre. Oops!

PS: Je complète ceci afin que nous ayons une liste complète des problèmes possibles lors du dépannage des mêmes symptômes.

— Hincor
source