254 votes

Comment rendre un tunnel SSH accessible au public ?

En se référant à こん J'exécute le programme ci-dessous via OpenSSH. (Client : Mac OS X 10.6 | Serveur : Linux Mint) Cependant, le port qui fait l'objet du tunnelage ne fonctionne pas publiquement :

ssh -R 8080:localhost:80 -N root@example.com
  • Le but est que le port local puisse être ouvert sur l'ordinateur distant.
  • Il semble que le côté distant se lie seulement sur localhost au lieu de toutes les interfaces
  • Cela fonctionne en ouvrant le port sur localhost sur l'ordinateur distant, mais lorsque j'essaie d'accéder à l'IP publique de l'ordinateur distant depuis mon ordinateur local, le port ne semble pas être ouvert.

Comment rendre le tunnel public sur l'IP pour que tout le monde puisse y accéder ?

0 votes

Que signifie l'IP public ? Si vous essayez de vous connecter à un ordinateur local par le biais du routeur et via Internet, la plupart des routeurs n'autorisent pas un tel bouclage.

480voto

JJ Wille Points 21

Si vous consultez la page de manuel de ssh, vous constaterez que la syntaxe de l'option -R lit :

\-R \[_bind\_address_:\]_port_:_host_:_hostport_

Lorsque _bind_address_ est omis (comme dans votre exemple), le port est lié à l'interface de bouclage uniquement. Pour qu'il soit lié à toutes les interfaces, utilisez

ssh -R \*:8080:localhost:80 -N root@example.com

ou

ssh -R 0.0.0.0:8080:localhost:80 -N root@example.com

ou

ssh -R "[::]:8080:localhost:80" -N root@example.com

La première version se lie à toutes les interfaces individuellement. La deuxième version crée une liaison générale IPv4-only, ce qui signifie que le port est accessible sur toutes les interfaces via IPv4. La troisième version est probablement équivalente à la première d'un point de vue technique, mais là encore, elle ne crée qu'une seule liaison à l'adresse suivante :: ce qui signifie que le port est accessible via IPv6 en mode natif et via IPv4 par l'intermédiaire d'un système d'exploitation. Adresses IPv4 mappées IPv6 (ne fonctionne pas sous Windows, OpenBSD).  (Vous avez besoin des guillemets car [::] pourrait être interprété comme un glob, sinon).

Notez que si vous utilisez OpenSSH sshd du serveur, le GatewayPorts L'option doit être activée ( clientspecified ou, dans de rares cas, à yes ) pour que cela fonctionne (vérifier le fichier /etc/ssh/sshd_config sur le serveur). Sinon (la valeur par défaut de cette option est no ), le serveur forcera toujours le port à être lié sur l'interface de bouclage uniquement.

17 votes

OH MON DIEU ÇA A MARCHÉ !!!!! J'ai fait exactement ça 1 million de fois ! !! J'ai juste oublié que * dans bash va donner des fichiers et j'avais besoin de \*

1 votes

Je me sens tellement stupide maintenant ! Mais merci !

6 votes

Ouais, c'est exactement pourquoi je préfère toujours 0.0.0.0 - c'est seulement IPv4, mais ça fera l'affaire la plupart du temps :)

47voto

Kurt Pattyn Points 1650

編集する。

-g fonctionne pour les ports transférés locaux, mais ce que vous voulez est un port transféré inverse/à distance, ce qui est différent.

Ce que vous voulez, c'est ce .

Essentiellement, sur example.com ensemble GatewayPorts=clientspecified en /etc/ssh/sshd_config .

--- réponse précédente (incorrecte) ---

Utilisez l'option -g. Extrait de la page de manuel de ssh :

-g     Allows remote hosts to connect to local forwarded ports.

0 votes

Ça ne semble pas fonctionner... ça démarre mais je ne peux pas me connecter à distance.

2 votes

Essayez d'exécuter netstat -elnpt à partir d'un autre terminal pour savoir quels ports sont liés à quelle adresse. Sans -g un port doit être lié à 127.0.0.1:PORT . Avec -g il doit être lié à 0.0.0.0:PORT ce qui le rend accessible à distance.

0 votes

19voto

Miguel Ping Points 352

Voici ma réponse pour compléter :

J'ai fini par utiliser ssh -R ... pour le tunnelage, et en utilisant socat en plus de cela pour rediriger le trafic réseau vers 127.0.0.1 :

tunnel lié à 127.0.0.1 : ssh -R mitm:9999:<my.ip>:8084 me@mitm

socat : mitm$ socat TCP-LISTEN:9090,fork TCP:127.0.0.1:9999

L'autre option est de faire un tunnel local seulement par dessus, mais je trouve ceci beaucoup plus lent

mitm$ ssh -L<mitm.ip.address>:9090:localhost:9999 localhost

0 votes

J'aime le fait que je n'ai pas à m'occuper de la configuration de sshd et que je peux faire tout cela sans sudo. De plus, j'apprends que socat existe. Merci !

2 votes

+Allez-y, mon bon monsieur. J'ai essayé de dire à ssh de se lier à 0.0.0.0 sans succès puis j'ai vu la syntaxe *, j'ai essayé, sans succès. J'imagine qu'il peut s'agir d'une sorte de fonction de sécurité dans la configuration de sshd ou quelque chose qui ne l'autorise pas. J'ai finalement vu ce message et socat a fonctionné de manière impressionnante. Super utile, je le mets dans ma poche arrière ;]

17voto

panticz Points 271

Vous pouvez également utiliser un double forward si vous ne voulez ou ne pouvez pas modifier /etc/ssh/sshd_config.

Transférer d'abord vers un port temporaire (par exemple 10080) sur le périphérique loopback de la machine distante, puis utiliser le transfert local pour rediriger le port 10080 vers 80 sur toutes les interfaces :

ssh -A -R 10080:localhost_or_machine_from:80 user@remote.tld "ssh -g -N -L 80:localhost:10080 localhost"

4 votes

Cela fonctionne en fait pour contourner les règles de redirection !

1 votes

J'adore cette solution. C'est un excellent moyen de contourner le problème lorsque vous ne voulez pas modifier la configuration de la machine.

0 votes

Ça marche, mais je ne sais pas pourquoi ça marche.

8voto

Breezeight Points 499

Utilisez l'option "ports de passerelle".

ssh -g -R REMOTE_PORT:HOST:PORT ...

Pour l'utiliser, vous devrez probablement ajouter " GatewayPorts yes "dans le répertoire de votre serveur /etc/ssh/sshd_config .

0 votes

En fait, ça a marché. Ce que je fais, c'est que j'utilise une instance EC2 comme transitaire vers mon serveur REST. De cette façon, je n'ai pas besoin de placer mon serveur dans la DMZ et je n'ai pas besoin d'une IP publique. C'est drôle, avec la première instance EC2 que j'ai créée, ssh -R remote_port:localhost:port xxx@ec2xxx a bien fonctionné, mais j'ai dû créer une autre instance plus tard pour une raison quelconque et à partir de ce moment-là, j'obtenais toujours : connexion refusée. J'ai utilisé tcpdump pour voir ce que je recevais et il n'y avait pas beaucoup d'informations. L'option -g plus GatewayPorts yes a fait l'affaire.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X