El túnel SSH no funciona

El túnel SSH no funciona

Utilizo el siguiente comando para crear un túnel ssh a mi servidor Ubuntu:

ssh -fNg -L 8888:127.0.0.1:22 -p 1000 username@server-address  -v

Luego configuré el proxy http y https de OSX en 127.0.0.1:8888

Y me salió el siguiente error:

SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2

El protocolo no coincide.

¿Cuál es el problema y cómo puedo solucionarlo?

Respuesta1

-L 8888:localhost:22 reenviará su puerto local 8888 al puerto 22 del servidor ssh. Mientras no haya un servidor squid u otro proxy ejecutándose, no funcionará.

SSH puede proporcionar un proxy de calcetines, que puede utilizar para navegar a través de su túnel ssh.

ssh -fNg -D 8888 -p 1000 username@server-address  -v

Simplemente configure su proxy después de conectarse:

localhost:8888

Respuesta2

Escribes "Utilizo el siguiente comando para crear un túnel ssh a mi servidor Ubuntu:

ssh -fNg -L 8888:127.0.0.1:22 -p 1000 nombre de usuario@dirección-servidor -v

Bien, entonces necesitarías tener un servidor SSH en el puerto 1000.

Bien, entonces el programa cliente se conectará al puerto 8888 y todo lo que envíe allí se reenviará al puerto 22 (siendo 22 el puerto comúnmente utilizado para ssh).

Supongo que si estuvieras intentando hacer un túnel ssh dentro de ssh, eso podría tener sentido, ¡aunque no puedo pensar en la necesidad de eso!

Luego configuré el proxy http y https de OSX en 127.0.0.1:8888"

No, ya tienes SSH abriendo un puerto escuchando en el puerto 8888. No puedes tener otra cosa escuchando en ese puerto.

Si coloca el proxy http[s] en el puerto 22 de la máquina de destino (dirección del servidor) y configura su navegador web para usar el proxy 127.0.0.1:8888, entonces su navegador web podría conectarse al puerto 8888 y se reenviará a el proxy http en el puerto 22 de la máquina de destino. Cuando lo hizo, -L 8888:127.0.0.1:22significa que debe tener algo escuchando en el puerto 22 de la máquina de destino. Y es posible que desees cambiar 22 a algo más sensato como 8080. No lo he probado pero creo que funcionaría.

Alternativamente, SSH también tiene una opción -D que actúa como un proxy SOCKS que puede hacer HTTP[s], pero le indica al navegador web que se conecte a un proxy SOCKS en lugar de a un HTTPS normal. Entonces supongo que, como dijo David, ssh -fNg -D 8888 -p 1000 username@server-address -v -fNg y -v no son esenciales, por supuesto.

información relacionada