¿Es posible reenviar solicitudes ssh que llegan a través de un puerto determinado a otra máquina?

Question

Tengo una pequeña red local.Sólo una de las máquinas está disponible para el mundo exterior (esto no se puede cambiar fácilmente).Me gustaría poder configurarlo de manera que las solicitudes ssh que no lleguen al puerto estándar vayan a otra máquina.es posible?¿Si es así, cómo?

Ah, y todas estas máquinas ejecutan Ubuntu u OS X.

Answer 1

Otra forma de hacerlo sería utilizar un túnel ssh (que ocurre en el lado del cliente).

Harías un comando ssh como este:

ssh -L 8022:myinsideserver:22 paul@myoutsideserver

Eso lo conecta a la máquina a la que se puede acceder desde el exterior (myoutsideserver) y crea un túnel a través de esa conexión ssh al puerto 22 (el puerto ssh estándar) en el servidor al que solo se puede acceder desde el interior.

Luego harías otro comando ssh como este (dejando el primero todavía conectado):

ssh -p 8022 paul@localhost

Esa conexión al puerto 8022 en su host local se canalizará a través de la primera conexión ssh que lo llevará a myinsideserver.

Es posible que deba hacer algo en myoutsideserver para permitir el reenvío del puerto ssh.Estoy comprobando eso dos veces ahora.

Editar

Mmm.La página de manual de ssh dice esto:**Solo el superusuario puede reenviar puertos privilegiados.**

Para mí, eso implica que la primera conexión ssh debe ser como root.Quizás alguien más pueda aclarar eso.

Parece que no se requieren privilegios de superusuario mientras el puerto reenviado (en este caso, 8022) no es un puerto privilegiado (como el 22).gracias por la aclaración mike piedra.

Answer 2

(En este ejemplo, asumo que el puerto 2222 irá a su host interno.$externalip y $internalip son las direcciones IP o nombres de host de la máquina visible e interna, respectivamente).

Tienes un par de opciones, dependiendo de qué tan permanente quieras que sea el proxy:

• Algún tipo de proxy TCP.En Linux, la idea básica es que antes Cuando se procesa el paquete entrante, desea cambiar su destino-es decir.NAT de destino de preenrutamiento:

  iptables -t nat -A PREROUTING -p tcp -i eth0 -d $externalip --dport 2222 --sport 1024:65535 -j DNAT --to $internalip:22

• Usar SSH para establecer un reenvío de puertos temporal.A partir de aquí, tienes nuevamente dos opciones:

  • Proxy transparente, donde el cliente piensa que su host visible (en el puerto 2222) es simplemente un servidor SSH normal y no se da cuenta de que está de paso.Si bien pierde algo de control detallado, obtiene comodidad (especialmente si desea usar SSH para reenviar VNC o X11 hasta el host interno).

    • Desde la máquina interna: ssh -g -R 2222:localhost:22 $externalip
    • Luego del mundo exterior: ssh -p 2222 $externalip

    Tenga en cuenta que las máquinas "internas" y "externas" no tienen que estar en la misma LAN.Puede reenviar puertos a todo el mundo de esta manera.

  • Forzar el inicio de sesión en la máquina externa primero.Esto es verdadero "reenvío", no "proxy";pero la idea básica es esta:Obligas a las personas a iniciar sesión en la máquina externa (de modo que controlas quién puede iniciar sesión y cuándo, y obtienes registros de la actividad), y desde allí pueden acceder mediante SSH al interior.Suena como una tarea ardua, pero si configure scripts de shell simples en la máquina externa con los nombres de sus hosts internos, junto con pares de claves SSH sin contraseña entonces es muy sencillo para un usuario iniciar sesión.Entonces:

    • En la máquina externa, creas un script simple, /usr/local/bin/internalhost que simplemente corre ssh $internalip
    • Desde el mundo exterior, los usuarios hacen: ssh $externalip internalhost y una vez que inician sesión en la primera máquina, se reenvían inmediatamente a la interna.

    Otra ventaja de este enfoque es que las personas no tienen problemas de administración de claves, ya que ejecutar dos servicios SSH en una dirección IP enojará al cliente SSH.

Para su información, si desea utilizar SSH en un servidor y no quiere preocuparse por las claves, haga esto

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

Tengo un alias en mi shell llamado "nossh", así que puedo hacer nossh somehost e ignorará todos los errores clave.Simplemente comprenda que está ignorando la información de seguridad al hacer esto, por lo que existe un riesgo teórico.

Gran parte de esta información proviene de una charla que di en el Barcamp Bangkok sobre trucos sofisticados de SSH.Puedes ver mis diapositivas, pero recomiendo el versión de texto ya que las diapositivas del S5 tienen algunos errores.Consulte la sección llamada "Reenviar cualquier cosa:Reenvío de puertos simple" para obtener información.También hay información sobre cómo crear un proxy SOCKS5 con OpenSSH.Si tu puedes hacerlo.OpenSSH es increíble así.

(Finalmente, si viajas mucho a la red interna, considera configurar una VPN.Suena aterrador, pero OpenVPN es bastante simple y se ejecuta en todos los sistemas operativos.Yo diría que es excesivo sólo para SSH;pero una vez que comience a reenviar puertos a través de sus reenvíos de puertos para que sucedan VNC, HTTP u otras cosas;o si tiene muchos hosts internos de los que preocuparse, puede ser más sencillo y más fácil de mantener).

Answer 3

@Mark Biek

Iba a decir eso, ¡pero me ganaste!De todos modos, sólo quería agregar que también existe la opción -R:

ssh -R 8022:myinsideserver:22 paul@myoutsideserver

La diferencia es a qué máquina te estás conectando.Mi jefe me mostró este truco no hace mucho y definitivamente es muy bueno saberlo...estábamos detrás de un firewall y necesitábamos dar acceso externo a una máquina...lo evitó mediante ssh -R a otra máquina a la que se podía acceder...luego, las conexiones a esa máquina se reenviaron a la máquina detrás del firewall, por lo que debe usar -R o -L según la máquina en la que se encuentre y a cuál esté realizando ssh.

Además, estoy bastante seguro de que puede utilizar un usuario normal siempre y cuando el puerto que está reenviando (en este caso, el puerto 8022) no esté por debajo del rango restringido (que creo que es 1024, pero podría estar equivocado). , porque esos son los puertos "reservados".No importa que lo esté reenviando a un puerto "restringido" porque ese puerto no está abierto (a la máquina solo se le envía tráfico a través del túnel, no tiene conocimiento del túnel), el puerto 8022 ES siendo abierto y por lo tanto está restringido como tal.

EDITAR:Solo recuerde, el túnel solo está abierto mientras el ssh inicial permanezca abierto, por lo que si se agota el tiempo o usted sale, el túnel se cerrará.

Answer 4

Puede utilizar Port Forwarding para hacer esto.Échale un vistazo aquí:

http://portforward.com/help/portforwarding.htm

Hay instrucciones sobre cómo configurar su enrutador para la solicitud de reenvío de puertos en esta página:

http://www.portforward.com/english/routers/port_forwarding/routerindex.htm

Answer 5

En Ubuntu, puedes instalar Iniciador de fuego y luego usarlo es Servicio directo función para reenviar el tráfico SSH desde un puerto no estándar en su máquina con acceso externo al puerto 22 en la máquina dentro de su red.

En OS X puedes editar el /etc/nat/natd.plist archivo para habilitar el reenvío de puertos.

Answer 6

Sin complicarse con las reglas del firewall, puede configurar un archivo ~/.ssh/config.

Supongamos que 10.1.1.1 es el sistema de "puerta de enlace" y 10.1.1.2 es el sistema de "cliente".

Host gateway
  Hostname 10.1.1.1 
  LocalForward 8022 10.1.1.2:22 

Host client
  Hostname localhost
  Port 8022

Puede abrir una conexión ssh a la 'puerta de enlace' a través de:

ssh gateway

En otra terminal, abra una conexión con el cliente.

ssh client