[email protected]$ autossh -R 12345:localhost:22 [email protected]
Más tarde:
[email protected]$ autossh -L 23456:localhost:12345 [email protected]
[email protected]$ ssh [email protected] -p 23456
Lo que podría hacer es esto:en el paso 1 reenvíe un puerto remoto desde la PC de la oficina al servidor (12345
se usa como ejemplo, cualquier puerto>1024 debería funcionar). Ahora conectarse a 12345 en el servidor debería conectarlo al puerto 22 en officepc.
En el paso 2, reenvía el puerto 23456 desde tu máquina doméstica al 12345 en el servidor (desde donde se reenvía a officepc:22, como se configuró en el paso 1)
En el paso 3, se conecta al puerto local 23456 con el inicio de sesión de su PC de oficina . Esto se reenvía en el paso 2 al puerto 12345 en su servidor y en el paso 1 a la PC de su oficina.
Tenga en cuenta que estoy usando autossh para los reenvíos, ya que es un envoltorio ssh que vuelve a conectar automáticamente el túnel en caso de que se desconecte; sin embargo, ssh normal también funcionaría, siempre que la conexión no se interrumpa.
Existe una posible vulnerabilidad:cualquiera que pueda conectarse a localhost:12345 en serverpc ahora puede conectarse a officepc:22 e intentar piratearlo. (Tenga en cuenta que si está ejecutando un servidor SSH, de todos modos debe asegurarlo por encima de las protecciones básicas que están activadas de forma predeterminada; recomiendo al menos deshabilitar el inicio de sesión raíz y deshabilitar la autenticación de contraseña; consulte, por ejemplo, esto)
Editar :He verificado esto con la misma configuración y funciona. GatewayPorts no
solo afecta a los puertos que están abiertos al mundo en general, no a los túneles locales. Estos son los puertos reenviados:
homepc:
outgoing ssh to serverpc:22
listening localhost:23456 forwarded through ssh tunnel
serverpc:
listening ssh at *:22
incoming localhost ssh tunnel (from homepc) forwarded to localhost:12345
listening localhost ssh tunnel (from officepc) forwarded from localhost:12345
officepc:
outgoing ssh to serverpc:22
incoming localhost through ssh tunnel (from serverpc) forwarded to localhost:22
Entonces, en lo que respecta a la pila de red, todo es tráfico local en las respectivas interfaces de loopback (más conexiones ssh a servidorpc); por lo tanto, GatewayPorts
no se comprueba en absoluto.
Sin embargo, existe la directiva AllowTcpForwarding
:si eso es no
, esta configuración fallará ya que no se permite ningún reenvío, ni siquiera a través de la interfaz de bucle invertido.
Advertencias :
-
si usa autossh y ssh reciente, es posible que desee usar
ServerAliveInterval
de ssh yServerAliveCountMax
por mantener el túnel arriba. Autossh tiene un control incorporado, pero aparentemente tiene algunos problemas en Fedora.-M0
deshabilita eso, y-oServerAliveInterval=20 -oServerAliveCountMax=3
comprueba si la conexión está activa:intenta cada 20 segundos, si falla 3 veces seguidas, detiene ssh (y autossh crea uno nuevo):autossh -M0 -R 12345:localhost:22 -oServerAliveInterval=20 -oServerAliveCountMax=3 [email protected] autossh -M0 -L 23456:localhost:12345 -oServerAliveInterval=20 -oServerAliveCountMax=3 [email protected]
-
podría ser útil reiniciar el túnel ssh si falla el reenvío, usando
-oExitOnForwardFailure=yes
- si el puerto ya está vinculado, es posible que obtenga una conexión SSH que funcione, pero no un túnel reenviado. -
usando
~/.ssh/config
para las opciones (y puertos) es aconsejable, de lo contrario, las líneas de comando se vuelven demasiado detalladas. Por ejemplo:Host fwdserverpc Hostname serverpc User notroot ServerAliveInterval 20 ServerAliveCountMax 3 ExitOnForwardFailure yes LocalForward 23456 localhost:12345
Entonces puede usar solo el alias del servidor:
autossh -M0 fwdserverpc
Si puede ssh al servidor interno desde casa y desde el servidor interno a la máquina Linux de su oficina, entonces desde casa puede usar ssh ProxyCommand
para rebotar silenciosamente a través del servidor a la máquina interna a través de nc
(netcat)
# ~/.ssh/config on your home machine:
Host internalpc
ForwardAgent yes
ProxyCommand ssh [email protected] exec nc internal.pc.example.com %p
Entonces solo ssh [email protected]
y se le reenvía silenciosamente a través de la máquina del servidor, sin necesidad de abrir puertos o túneles en ninguno de los extremos.
Instale Robo-TiTO en la computadora a la que desea acceder SSH de forma remota.
- Esto le permitirá acceder a SSH usando Google Talk Client Apps en cualquier lugar.
- No hay necesidad de una dirección IP pública o una configuración especial.
- Es gratis y de código abierto, ya no paga ningún servicio de aplicación.
- No es necesario abrir el puerto SSH (mantenga su computadora segura).
- No es necesario abrir ningún túnel (por ejemplo, VPN o algo así)
Las siguientes instrucciones de instalación están obsoletas, ya que el sitio se ha movido. La nueva URL es https://github.com/formigarafa/robotito
Hice un script (probado en mi sistema operativo Raspbian en Raspberry Pi) para que pueda instalar fácilmente Robo-TiTO en Raspberry Pi, Debian o Ubuntu Box (distribución del paquete Debian). Estos son los pasos para obtener su Linux caja controlable:
Abra Shell Command o puede llamarlo Terminal, vaya a su carpeta de inicio, descargue el script de instalación por comando:
$ wget https://opengateway.googlecode.com/files/robotito
después de eso, ejecute el script ingresando el comando:
$ sudo ./robotito
y luego puedes editar el archivo
credentials.rb
desde la carpeta de configuración de Robo-TiTO usando su cuenta de GTalk y guárdelo presionando Ctrl +X y Y . El valor predeterminado es usar el editor nano.ejecutando el Robo-TiTO desde la carpeta Robo-TiTO por comando
$ cd robotito $ ./jabbershd start
Ahora que esto está hecho, puede usar SSH desde cualquier cliente de Google Talk. No olvide agregar la cuenta de Robo-TiTO GTalk a su cuenta de Google Talk y pruébela conversando entre ellos antes de usar la cuenta.