¿Cómo hacer que el túnel ssh esté abierto al público?

174

Bueno, refiriéndome a esta pregunta, estoy ejecutando el comando

ssh -R 8080:localhost:80 -N [email protected]

en una Mac Sin embargo, el puerto que se está tunelizando no funciona públicamente. Estoy ejecutando dicho comando para que se pueda abrir el puerto local en la computadora remota. Y funciona al abrir el puerto en localhost en la computadora remota, pero cuando intento acceder a la dirección IP pública de la computadora remota desde mi computadora local, el puerto no parece estar abierto. ¿Cómo haría público el túnel en la IP para que cualquiera pueda acceder?

EDITAR: Parece que el lado remoto se une solo en localhost en lugar de a todas las interfaces.

EDIT 2: el cliente es Mac OS X 10.6 y el servidor es Linux Mint, pero ambos son OpenSSH.

ssh ip openssh ssh-tunnel Trevor Rudolph
fuente
¿Qué significa IP pública? Si está intentando conectarse a una computadora local a través del enrutador y a través de Internet, la mayoría de los enrutadores no permitirán tal bucle invertido.
harrymc

Respuestas:

351

Si revisa la página de manual para ssh, encontrará que la sintaxis de -Rlee:

-R [ bind_address :] puerto : host : hostport

Cuando bind_addressse omite (como en su ejemplo), el puerto está vinculado únicamente a la interfaz de bucle invertido. Para que se una a todas las interfaces, use

ssh -R \*:8080:localhost:80 -N [email protected]

o

ssh -R 0.0.0.0:8080:localhost:80 -N [email protected]

o

ssh -R "[::]:8080:localhost:80" -N [email protected]

La primera versión se une a todas las interfaces individualmente. La segunda versión crea un enlace general solo IPv4, lo que significa que el puerto es accesible en todas las interfaces a través de IPv4. La tercera versión es probablemente técnicamente equivalente a la primera, pero de nuevo solo crea un enlace ::, lo que significa que el puerto es accesible a través de IPv6 de forma nativa y a través de IPv4 a través de direcciones IPv6 asignadas por IPv4 (no funciona en Windows, OpenBSD) . (Necesita las comillas porque de [::]lo contrario podría interpretarse como un globo).

Tenga en cuenta que si usa el sshdservidor OpenSSH , la GatewayPortsopción del servidor debe estar habilitada (establecida en yeso clientspecified) para que esto funcione (verifique el archivo /etc/ssh/sshd_configen el servidor). De lo contrario (el valor predeterminado para esta opción es no), el servidor siempre forzará al puerto a vincularse solo en la interfaz de bucle invertido.

Stefan Seidel
fuente
12
¡OH DIOS MÍO, FUNCIONÓ! ¡He hecho exactamente eso 1 millón de veces! Acabo de olvidar que *en bash dará archivos y lo necesitaba\*
Trevor Rudolph
44
Sí, eso es exactamente por lo que siempre prefiero 0.0.0.0: es solo IPv4, pero lo hará la mayor parte del tiempo :)
Stefan Seidel
34
GatewayPorts sí resolvió mi problema.
Sunry
44
GatewayPorts = yes (en la configuración sshd remota) también lo arregló para mí
Phil_1984_
3
"GatewayPorts yes" me alegró el día, gracias @StefanSeidel
karser
37

Editar:

-g funciona para puertos reenviados locales, pero lo que desea es un puerto reenviado inverso / remoto, que es diferente.

Lo que quieres es esto .

En esencia, el example.com, ajuste GatewayPorts=clientspecifieden /etc/ssh/sshd_config.

--- respuesta anterior (incorrecta) ---

Use la opción -g. Desde la página de manual de ssh:

-g     Allows remote hosts to connect to local forwarded ports.
zapata
fuente
no parece estar funcionando ... se inicia pero no puedo conectarme de forma remota
Trevor Rudolph
2
Intente ejecutar netstat -elnptdesde un tty separado para averiguar qué puertos están vinculados a qué dirección. Sin -gun puerto debería estar vinculado 127.0.0.1:PORT. Con -g, debe estar vinculado a 0.0.0.0:PORT, lo que lo hace accesible de forma remota.
zapatero
pastebin.com/q6f4kJyd
Trevor Rudolph
2
GatewayPorts=clientspecifiedoGatewayPorts clientspecified
Trevor Rudolph
¿y lo agrego al cliente o al control remoto?
Trevor Rudolph
14

Aquí está mi respuesta para completar:

Terminé usando ssh -R ...para hacer túneles, y socatademás para redirigir el tráfico de red a 127.0.0.1:

túnel unido a 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

Otra opción es hacer un túnel solo local además de eso, pero me parece mucho más lento

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

Miguel Ping
fuente
Me gusta el hecho de que no tengo que lidiar con la configuración de sshd y que puedo hacerlo todo sin sudo. Además, aprendo que el socat existe. ¡Gracias!
BrutusCat
+ arriba vas bien señor. Traté de decirle a ssh que se uniera a 0.0.0.0 sin éxito ... luego vi la sintaxis *, probé eso, sin dados. Me imagino que puede ser algún tipo de característica de seguridad en la configuración de sshd o algo que no lo permite. Finalmente vi esta publicación y socatfuncionó de maravilla. Súper útil, poner esto en mi bolsillo trasero;]
Jaime
10

También puede usar un reenvío doble si no puede o puede cambiar / etc / ssh / sshd_config.

Primero reenvíe al puerto temporal (por ejemplo, 10080) en el dispositivo de bucle invertido en la máquina remota, luego use el reenvío local allí para redirigir el puerto 10080 a 80 en todas las interfaces:

ssh -A -R 10080:localhost_or_machine_from:80 [email protected] "ssh -g -N -L 80:localhost:10080 localhost"
panticz.de
fuente
1
¡Esto realmente funciona para evitar las reglas de reenvío!
Michael Schubert
Amo esta solución. Gran solución cuando no desea cambiar la configuración de la máquina
Grezzo
8

Use la opción "puertos de puerta de enlace".

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

Para usar eso, probablemente necesite agregar " GatewayPorts yes" a su servidor /etc/ssh/sshd_config.

Raúl Salinas-Monteagudo
fuente
En realidad esto funcionó. Lo que hago es usar una instancia EC2 como reenviador a mi servidor REST. De esta manera, no necesito pegar mi servidor en la DMZ y no necesito una IP pública. Curiosamente, con la primera instancia EC2 que creé, ssh -R remote_port: localhost: port xxx @ ec2xxx funcionó bien, pero luego tuve que crear otra instancia más tarde por alguna razón y desde ese momento, siempre estaba obteniendo: conexión rechazado Usé tcpdump para ver lo que estaba obteniendo y no había mucha información. -g plus GatewayPorts sí hizo el truco.
ET
1

Los hosts de salto son una adición bastante reciente a OpenSSH. Esto requiere acceso SSH al intermedio, pero debería funcionar sin configuración adicional.

ssh -J [email protected] remoteuser@localhost -p 8080

Este comando le indica a SSH que primero se conecte [email protected]y luego, desde esa máquina, inicie una conexión al puerto 8080 en localhost(es decir, el puerto que se canaliza desde el host de salto al host remoto) bajo el remoteusernombre de usuario.

krlmlr
fuente
0

Si desea poner la configuración en usted en ~/.ssh/configlugar de usar parámetros de línea de comando, puede intentar algo como

Host REMOTE_HOST_NAME RemoteForward \*:8080 127.0.0.1:80

Recuerde que el firewall del host remoto permite conexiones al 8080 y asegúrese de que la GatewayPortsopción de su /etc/ssh/sshdconfiguración no esté configurada enno

Brad Mostert
fuente