Question Comment rendre le tunnel ssh ouvert au public?


Eh bien, renvoyant à ce question, je lance la commande

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

sur un Mac Pourtant, le port en cours de tunnel ne fonctionne pas publiquement. J'exécute une telle commande pour que le port local puisse être ouvert sur l'ordinateur distant. Et cela fonctionne quand on ouvre le port sur localhost sur l'ordinateur distant, mais quand j'essaie d'accéder à l'adresse IP publique de l'ordinateur distant à partir de mon ordinateur local, le port ne semble pas être ouvert. Comment puis-je rendre le tunnel public sur l’IP pour que quiconque puisse y accéder?

EDIT: Il semble que le côté distant ne se lie que sur localhost plutôt que sur toutes les interfaces.

EDIT 2: Le client est Mac OS X 10.6 et le serveur est Linux Mint, mais ils sont tous deux OpenSSH.


137
2018-04-27 22:14


origine


Que signifie IP publique? Si vous essayez de vous connecter à un ordinateur local via le routeur et via Internet, la plupart des routeurs ne permettent pas un tel bouclage. - harrymc


Réponses:


Si vous vérifiez la page de manuel pour ssh, vous constaterez que la syntaxe pour -R lit:

-R [bind_address:]Port:hôte:port hôte

Quand bind_address est omis (comme dans votre exemple), le port est uniquement lié à l'interface de bouclage. Pour le rendre 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 est liée à toutes les interfaces individuellement. La deuxième version crée une liaison générale IPv4 uniquement, ce qui signifie que le port est accessible sur toutes les interfaces via IPv4. La troisième version est probablement techniquement équivalente à la première, mais là encore, elle ne crée qu’un lien ::, ce qui signifie que le port est accessible via IPv6 en mode natif et via IPv4 via Adresses IPv6 mappées IPv4 (ne fonctionne pas sous Windows, OpenBSD). (Vous avez besoin des citations car [::] pourrait être interprété comme un glob sinon.)

Notez que si vous utilisez OpenSSH sshd serveur, le serveur GatewayPorts l'option doit être activée (mis à yes ou clientspecified) 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é à l’interface de bouclage uniquement.


282
2018-05-06 06:11



OH MON DIEU A TRAVAILLÉ !!!!! J'ai fait exactement 1 million de fois !! J'ai juste oublié ça * en bash donnera des fichiers et j'avais besoin \* - Trevor Rudolph
Ouais, c'est exactement pourquoi je préfère toujours 0.0.0.0 - ce n'est que IPv4, mais il le fera la plupart du temps :) - Stefan Seidel
GatewayPorts oui a résolu mon problème. - Sunry
GatewayPorts = yes (sur la configuration sshd distante) corrigé pour moi aussi - Phil_1984_
"GatewayPorts oui" a fait ma journée, merci @StefanSeidel - karser


Modifier:

-g fonctionne pour les ports transférés locaux, mais ce que vous voulez, c'est un port transféré inversé / distant, ce qui est différent.

Ce que vous voulez est ce.

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

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

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

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

32
2018-04-28 03:34



ne semble pas fonctionner ... ça démarre mais je ne peux pas me connecter à distance - Trevor Rudolph
Essayer de courir netstat -elnpt à partir d'un tty séparé pour déterminer quels ports sont liés à quelle adresse. Sans pour autant -g, un port devrait être lié à 127.0.0.1:PORT. Avec -g, il devrait être lié à 0.0.0.0:PORT, ce qui le rend accessible à distance. - snapshoe
pastebin.com/q6f4kJyd - Trevor Rudolph
GatewayPorts=clientspecified ou GatewayPorts clientspecified - Trevor Rudolph
et puis-je l'ajouter au client ou à distance? - Trevor Rudolph


Voici ma réponse pour compléter:

J'ai fini par utiliser ssh -R ... pour tunneling et utilisation 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

Une autre option est de faire un tunnel uniquement local en plus de cela, mais je trouve cela beaucoup Ralentissez

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


10
2017-10-29 12:09



J'aime le fait que je n'ai pas à gérer la configuration de sshd et que je puisse tout faire sans sudo. De plus, j'apprends que socat existe. Merci! - BrutusCat


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

Transférer d'abord vers le port temporaire (par exemple 10080) sur le périphérique de bouclage sur 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"

8
2017-08-01 22:37



Cela fonctionne pour contourner les règles de transmission! - Michael Schubert
J'adore cette solution. Excellente solution de contournement lorsque vous ne souhaitez pas modifier la configuration de la machine - Grezzo


Utilisez l'option "ports passerelles".

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

Pour l'utiliser, vous devez probablement ajouter "GatewayPorts yes"à votre serveur" /etc/ssh/sshd_config.


6
2018-04-28 13:58



En fait, cela a fonctionné. Ce que je fais, c'est que j'utilise une instance EC2 en tant que redirecteur vers mon serveur REST. De cette façon, je n'ai pas besoin de coller mon serveur dans la DMZ et je n'ai pas besoin d'une adresse IP publique. Assez drôle, avec la première instance EC2 que j'ai créée, ssh -R remote_port: localhost: le port xxx @ ec2xxx fonctionnait très bien, mais j'ai dû créer une autre instance plus tard pour une raison quelconque et à partir de là, j'ai toujours eu: connection refusé. Utilisé tcpdump pour voir ce que je recevais et il n'y avait pas beaucoup d'informations. -g plus GatewayPorts oui a fait l'affaire. - E.T


Si vous souhaitez mettre la configuration en vous ~/.ssh/config au lieu d'utiliser des paramètres de ligne de commande, vous pouvez essayer quelque chose comme

Host REMOTE_HOST_NAME RemoteForward \*:8080 127.0.0.1:80

Rappelez-vous que le pare-feu de votre hôte distant autorise les connexions au 8080 et que le GatewayPorts option de votre /etc/ssh/sshd la configuration n'est pas définie sur no


0
2017-08-26 15:50