Connexion SSH -L réussie, mais le transfert de port de localhost ne fonctionne pas "channel 3 : open failed : connect failed : Connexion refusée"

Question

Mon laboratoire utilise RStudio sur un serveur. Il y a quelques semaines, depuis la maison de mon cousin, j'ai réussi à me connecter au serveur et à faire apparaître RStudio côté serveur via mon navigateur Firefox local. Maintenant, lorsque j'essaie d'accéder au RStudio du serveur depuis chez moi (via mon propre routeur), cela ne fonctionne pas. J'ai besoin d'aide pour le dépannage, et je suppose que c'est un problème sur le routeur. J'utilise Mac OSX 10.6.8. Je n'ai aucune idée de ce que le serveur de l'université exécute, mais je ne pense pas qu'il s'agisse d'un problème côté serveur.

Voici comment cela a fonctionné la première fois que je l'ai fait, chez mon cousin : d'abord, je me connecte par VPN au réseau de l'université ; ensuite, j'appelle SSH avec transfert de port ; puis j'ouvre un navigateur Firefox, je me connecte à mon port localhost, et cela ouvre RStudio du côté serveur auquel je peux accéder par la fenêtre de mon navigateur local.

Voici le problème que je rencontre actuellement lorsque j'essaie de me connecter à partir de mon réseau domestique :

Je peux établir la connexion VPN avec succès. Je peux également configurer SSH avec succès avec cette commande : ssh -v -L 8783:localhost:8783 myacct@server.com

Voici les dernières lignes de la sortie verbeuse de la commande ssh réussie :

debug1: Authentication succeeded (password).
debug1: Local connections to LOCALHOST:8783 forwarded to remote address localhost:8783
debug1: Local forwarding listening on 127.0.0.1 port 8783.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on ::1 port 8783.
debug1: channel 1: new [port listener]
debug1: channel 2: new [client-session]
debug1: Entering interactive session.
Last login: Mon Sep  2 04:02:40 2013 from vpnipaddress

Je pense donc que je réussis toujours à l'étape VPN et SSH (bien que je ne sache pas pourquoi il est indiqué que ma dernière connexion remonte au 2 septembre alors que je me suis connecté plusieurs fois depuis).

Ensuite, j'ouvre Firefox, et je tape localhost:8783, et au lieu d'obtenir une application serveur RStudio par la fenêtre de mon navigateur, j'obtiens les erreurs suivantes :

Dans la fenêtre du navigateur Firefox, il est écrit : Server not found, Firefox can't find the server at www.localhost.com, Check the address for typing errors etc.

Dans la fenêtre du terminal, ça dit :

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

Je ne suis pas sûr de ce que j'ai fait de mal. Je n'ai rien changé sur mon ordinateur portable depuis ma dernière connexion réussie. Je suis sur mon propre routeur (au lieu de celui de mon cousin), alors peut-être dois-je modifier le pare-feu ? J'ai déjà autorisé les ports 22 et 8783 à traverser le pare-feu pour atteindre mon ordinateur portable (je ne suis même pas sûr que ce soit nécessaire). Comment faire ?

Answer 1

ssh -v -L 8783:localhost:8783 myacct@server.com
...
channel 3: open failed: connect failed: Connection refused

Lorsque vous vous connectez au port 8783 sur votre système local, cette connexion est tunnelisée à travers votre lien ssh vers le serveur ssh sur serveur.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.

Answer 2

Je poste ceci pour aider quelqu'un.

Symptôme :

channel 2: open failed: connect failed: Connection refused
debug1: channel 2: free: direct-tcpip:
   listening port 8890 for 169.254.76.1 port 8890,
   connect from ::1 port 52337 to ::1 port 8890, nchannels 8

Mon scénario : je devais utiliser le serveur distant comme hôte de bastion pour me connecter ailleurs. Destination/cible finale : 169.254.76.1, port 8890. Via un serveur intermédiaire avec une adresse IP publique : ec2-54-162-180-7.compute-1.amazonaws.com

Commande de transfert de port local SSH :

ssh -i ~/keys/dev.tst -vnNT -L :8890:169.254.76.1:8890
glue@ec2-54-162-180-7.compute-1.amazonaws.com

Quel était le problème : Il n'y avait pas de service lié sur le port 8890 dans l'hôte cible. J'avais oublié de démarrer le service.

Comment ai-je résolu le problème ?

SSH dans l'hôte bastion et ensuite faire curl.

J'espère que cela vous aidera.

Answer 3

_Note : localhost est le nom d'hôte d'une adresse utilisant l'interface réseau locale (loopback), et 127.0.0.1 est son IP dans le Norme de réseau IPv4 (c'est ::1 en IPv6). 0.0.0.0 est l'adresse IP standard "réseau actuel" de l'IPv4._

J'ai rencontré cette erreur avec une configuration Docker. J'avais un conteneur Docker fonctionnant sur un serveur externe, et j'avais (correctement) mappé ses ports en tant que 127.0.0.1:9232:9232 . Par le transfert de port ssh remote -L 9232:127.0.0.1:9232 Je m'attendais à pouvoir communiquer avec le personnel de l'entreprise. remote le port du serveur 9232 comme si c'était mon propre port local.

Il s'est avéré que le conteneur Docker exécutait en interne son processus sur 127.0.0.1:9232 plutôt que 0.0.0.0:9232 Ainsi, même si j'avais correctement spécifié les mappages de port du conteneur, ils n'étaient pas sur la bonne interface pour être mappés.

Answer 4

Dans mon cas, cela a fonctionné après avoir exécuté le vncserver sur linux.

1. J'ai entré ceci sur la ligne de commande linux : sudo ssh -L 5901:localhost:5901 -i <ssh_private_key> <username>@<public-IP-address>
2. Type là vncserver
3. Allez dans l'application VncViewer et connectez-vous en utilisant localhost:5901

Answer 5

J'ai rencontré le même problème parce que 'localhost' n'était pas disponible sur le serveur lorsqu'il redémarrait le service réseau, par exemple avec 'ifdown -a' mais suivi par seulement 'ifup -eo1'. Outre le fait que le serveur n'écoute pas le port, vous pouvez également vérifier si 'localhost' est disponible ou non.

ps : Je le poste juste dans l'espoir que quelqu'un qui a le même problème puisse en bénéficier.