le tunnel ssh refuse les connexions avec "channel 2 : open failed" (canal 2 : ouverture échouée)

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 - j'ai essayé d'accéder à un port différent de celui que j'avais spécifié sur l'hôte distant.

J'ai juste pensé que je devais partager cela, bien que ce ne soit probablement pas la raison pour laquelle la plupart d'entre vous rencontrent cette erreur.

Pour le bénéfice des autres qui ont fait une erreur stupide comme moi (une erreur qui n'est pas mentionnée dans les autres réponses) : Assurez-vous que votre machine distante a bien un processus qui écoute sur le port vers lequel vous essayez de vous connecter !

Comme le dit @Kenster ici :

Lorsque vous vous connectez au port 8783 sur votre système local, cette connexion est tunnelisée via votre lien ssh vers le serveur ssh sur server.com. De là, le serveur ssh établit une connexion TCP avec le port 8783 de localhost et relaie les données entre la connexion tunnelée et la connexion à la cible du tunnel. L'erreur "connexion refusée" provient du serveur ssh sur server.com lorsqu'il tente d'établir la connexion TCP avec la cible du tunnel. "Connexion refusée" signifie qu'une tentative de connexion a été rejetée. L'explication la plus simple de ce rejet est que, sur server.com, il n'y a rien qui écoute les connexions sur le port 8783 de localhost. En d'autres termes, le logiciel serveur vers lequel vous avez essayé d'établir un tunnel n'est pas en cours d'exécution, ou bien il est en cours d'exécution mais n'écoute pas sur ce port.

Vérifiez d'abord que votre processus distant est en cours d'exécution, puis qu'il écoute effectivement sur le port auquel vous essayez de vous connecter.

Sur votre machine distante, vous pouvez exécuter l'un de ces programmes (en fonction des paquets disponibles sur votre distribution) pour vérifier quels ports sont écoutés :

sudo lsof -i -P -n | grep LISTEN
sudo netstat -tulpn | grep LISTEN
sudo ss -tulpn | grep LISTEN

Si votre commande est ssh -L -N 7000:127.0.0.1:6000 user@host et que vous ne voyez rien écouter sur 6000, alors c'est votre problème - vous devez trouver pourquoi le processus n'écoute pas sur un port, ou sur le port que vous attendez.

Il manque l'adresse IP --ip=n.n.n.n à la fin de la ligne. Vous devez spécifier exactement l'IP à connecter.

Ce qui a marché pour moi, c'est de changer l'ordre des commandes.

Donc, en gros

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

Étrange