Pregunta ¿Cómo hacer que el túnel ssh se abra al público?


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

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

en una Mac. Sin embargo, el puerto que se está tunelizando no está funcionando públicamente. Estoy ejecutando dicho comando para que el puerto local se pueda abrir 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é que el túnel sea público en el IP para que cualquiera pueda acceder?

EDITAR: Parece como si el lado remoto se conecta solo a 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.


137


origen


¿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 ese bucle. - harrymc


Respuestas:


Si revisa la página man para ssh, encontrará que la sintaxis para -R lee:

-R [bind_address:]Puerto:anfitrión:Puerto host

Cuando bind_address se omite (como en su ejemplo), el puerto está limitado a la interfaz de bucle invertido solamente. Para hacer que se una a todas las interfaces, use

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

o

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

o

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

La primera versión se une a todas las interfaces de forma individual. La segunda versión crea un enlace general solo para 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 nuevamente crea solo un enlace único a ::, lo que significa que se puede acceder al puerto a través de IPv6 de forma nativa y a través de IPv4 a través de Direcciones IPv6 mapeadas IPv4 (no funciona en Windows, OpenBSD). (Necesitas las cotizaciones porque [::] podría ser interpretado como un glob de otra manera.)

Tenga en cuenta que si usas OpenSSH sshd servidor, el servidor GatewayPorts la opción debe estar habilitada (ajustado a yes o clientspecified) para que esto funcione (ver archivo /etc/ssh/sshd_config en el servidor). De lo contrario (el valor predeterminado para esta opción es no), el servidor siempre forzará que el puerto se vincule solo en la interfaz de bucle invertido.


281



OH MI DIOS FUNCIONABA !!!!! ¡He hecho exactamente eso 1 millón de veces! Me olvidé de eso * en bash dará archivos y yo necesitaba \* - Trevor Rudolph
Sí, es exactamente por eso que siempre prefiero 0.0.0.0 - solo es IPv4, pero lo hará la mayor parte del tiempo :) - Stefan Seidel
GatewayPorts sí resolvió mi problema. - Sunry
GatewayPorts = yes (en la configuración remota de sshd) también lo solucionó - Phil_1984_
"GatewayPorts sí" hizo mi día, gracias @StefanSeidel - karser


Editar:

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

Lo que quieres es esta.

Esencialmente, en example.comestablecer GatewayPorts=clientspecified en /etc/ssh/sshd_config.

--- respuesta anterior (incorrecta) ---

Use la opción -g. De la página man de ssh:

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

32



no parece estar funcionando ... se inicia pero no puedo conectar de forma remota - Trevor Rudolph
Prueba correr netstat -elnpt de un tty separado para descubrir qué puertos están vinculados a qué dirección. Sin -g, un puerto debe estar obligado a 127.0.0.1:PORT. Con -g, debe estar obligado a 0.0.0.0:PORT, que lo hace accesible de forma remota. - snapshoe
pastebin.com/q6f4kJyd - Trevor Rudolph
GatewayPorts=clientspecified o GatewayPorts clientspecified - Trevor Rudolph
y lo agrego al cliente o control remoto? - Trevor Rudolph


Aquí está mi respuesta para completar:

Terminé usando ssh -R ... para tunelización y uso socat Además de eso para redirigir el tráfico de red a 127.0.0.1:

túnel enlazado 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 encuentro esto mucho más lento

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


10



Me gusta el hecho de que no tengo que lidiar con la configuración sshd y que puedo hacer todo sin sudo. Además, sé que Socat existe. ¡Gracias! - BrutusCat


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

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

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

8



¡Esto realmente funciona para eludir las reglas de reenvío! - Michael Schubert
Amo esta solución Gran solución cuando no quiere cambiar la configuración de la máquina - Grezzo


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

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

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


6



En realidad, esto funcionó. Lo que hago es usar una instancia EC2 como reenviador para mi servidor REST. De esta manera, no necesito colocar mi servidor en la DMZ y no necesito una IP pública. Curiosamente, con la primera instancia de EC2 que creé, ssh -R puerto_remoto: localhost: puerto xxx @ ec2xxx funcionó bien, pero luego tuve que crear otra instancia más adelante por algún motivo y desde ese momento, siempre recibía: conexión rechazado Usé tcpdump para ver lo que obtenía y no había mucha información. -g plus GatewayPorts sí hizo el truco. - E.T