tunnel ssh refusant les connexions avec "canal 2: échec d'ouverture"
Tout d'un coup (lire: sans modifier aucun paramètre) ma machine virtuelle netbsd a commencé à agir bizarrement. Les symptômes concernent le tunnelage ssh.
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 également 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é d'exécuter tcpdump sur 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 ce pourrait être le pilote de la carte réseau virtuelle, ou quelqu'un a rooté notre ssh.
Des idées ..?
Problème résolu:
$ ssh -L 7000:127.0.0.1:7000 user@Host -N -v -v
... apparemment, 'localhost' n'était pas apprécié par l'hôte distant. Pourtant, à distance /etc/hosts contient:
::1 localhost localhost.
127.0.0.1 localhost localhost.
tandis que l'interface 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. tellement pour la générosité de 100rp je mets :)
Bien que le problème d'OP ait déjà été résolu, j'ai décidé de partager la solution de 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, j'ai dû me connecter au service qui n'écoute que sur IPv6. J'ai essayé:
ssh -f [email protected] -L 51005: 127.0.0.1: 51005 -N ssh -f [email protected] -L 51005: localhost: 51005 -N
et quelques autres façons, mais cela n'a pas fonctionné. Tout essai de connexion à http://localhost:51005 provoque des erreurs comme celle-ci: channel 2: open failed: connect failed: Connection refused
La solution est:
ssh -f [email protected] -L 51005: [:: 1]: 51005 -N
L'adresse IPv6 doit être entre crochets.
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 se produire si un pare-feu bloque le port 7000, mais vous l'aviez déjà exclu. (Si les lecteurs ultérieurs ne l'ont pas exclu, regardez la sortie de netstat --numeric-ports.)
I pensez J'ai peut-être vu ce message d'erreur il y a longtemps, lorsque ssh a pris connaissance des adresses IPV6 après 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").
"... apparemment, 'localhost' n'était pas apprécié par l'hôte distant. Pourtant,/etc/hosts distant contient:"
Sauf que vous exécutiez ssh sur le client, "localhost" n'a donc pas été apprécié par votre client. Le fichier/etc/hosts distant est destiné aux connexions de connexion à distance out et non entrant.
J'ai rencontré cette même erreur en essayant de me connecter à mysql sur un autre serveur via un tunnel ssh. J'ai trouvé que le paramètre bind-address dans /etc/my.cnf sur le serveur cible était lié à mon adresse IP externe (dual NIC server) plutôt qu'interne, pour lequel je n'avais aucune utilité.
Lorsque j'ai défini bind-address = 127.0.0.1, j'ai pu utiliser correctement mon tunnel ssh comme suit:
ssh -N -f -L 3307:127.0.0.1:3306 [email protected]
mysql -h 127.0.0.1 --port=3307 --protocol=TCP -uusername -ppassword
J'ai rencontré cette erreur lorsque je transmettais des ports avec nom de domaine complet au lieu de localhost:
ssh -L 5900:Host.name.com:5900 x11vnc
Le port était ouvert uniquement pour localhost, donc pour accepter les connexions avec un nom complet, j'ai dû ajouter une description 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-les avec parcimonie).
L'interprétation alternative est, dans mon cas, votre faute de frappe.
user@Host ~ $ ssh -vvvNL 4444:127.0.0.0.1:4444
...
channel 2: open failed: connect failed: Name or service not known
Ce qui se passe ici, c'est que l'adresse IP a un trop grand nombre de zéros, ce qui n'est pas une adresse valide. Donc ssh le traite comme un nom de domaine à la place 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.
Pour moi, l'ajout de ":" fonctionne donc la commande dans votre cas ressemblerait à ceci:
ssh -L :7000:localhost:7000 user@Host -N -v
???
canal 2: échec d'ouverture: échec de connexion: connexion refusée
À user@Host il n'y a rien à écouter sur le port 7000, c'est simple et c'est tout.
Pour moi, j'essayais ssh -L <port>:<remote server IP>:<port> <login>@<remote server IP> quand j'aurais dû faire ssh -L <port>:127.0.0.1:<port> <login>@<remote server IP>.
J'espère que ça aidera quelqu'un!
J'ai reçu le même message d'erreur:
canal 3: échec d'ouverture: échec de connexion: connexion refusée
Et la cause était une erreur humaine - j'essayais d'accéder à un port différent sur l'hôte distant que celui que j'ai spécifié.
Je pensais juste partager cela, bien que ce ne soit probablement pas la raison pour laquelle la plupart d'entre vous rencontrez cette erreur.
Il lui manque l'adresse IP --ip=n.n.n.n à la fin de la ligne. Vous devez spécifier exactement quelle IP connecter.
Ce qui a fonctionné pour moi, c'était de changer l'ordre des commandes.
Donc en gros -
$ ssh user @ Host -L 7000: localhost: 7000 -N
Étrange