Disculpas si ya se me ha preguntado esto antes, pero actualmente estoy tratando de encontrar una solución que nos permita establecer conexiones SSH de manera similar a como funcionaría una puerta de enlace RDP. Para aquellos que no están familiarizados, RDP Gateway le permite esencialmente proxy de conexiones RDP a través de otro servidor. Escritorio remoto se autenticará de forma transparente con el servidor de puerta de enlace RDP y establecerá la conexión al servidor de punto final desde allí, lo que le permitirá hacer referencia a los servidores de punto final mediante direcciones IP privadas o nombres DNS internos, lo que limita su exposición.
Actualmente, lo que estoy pensando es configurar el reenvío de puertos a través de SSH para que cada servidor al que necesitemos poder acceder detrás del proxy del túnel esté en un puerto diferente que está siendo reenviado por el servidor de punto medio. Sin embargo, esto no parece una solución óptima, por lo que me interesa saber si existe una mejor manera de hacerlo.
Respuesta1
En términos SSH, a menudo se habla de unanfitrión bastiónoservidor de salto- una sola máquina (normalmente en su DMZ) que acepta conexiones SSH entrantes y desde la cual luego puede realizar una conexión SSH a los sistemas reales que administra.
==> | Server1 |
_________ ___________ / ---------
| user PC | ===(SSH on port 22)===> | jump host | ===(SSH on port 22)== ==+> | Server2 |
_________ ___________ \ _________
==> | Server3 |
A menudo, para mejorar la seguridad, el servidor de salto requerirá autenticación de doble factor y/o solo aceptará sesiones SSH entrantes después de establecer una conexión VPN.
En lugar de iniciar sesión primero en el host de salto y desde el símbolo del sistema iniciar la segunda sesión SSH, OpenSSH le permite configurar eso con un solo comando.
Prefiero establecer todas las configuraciones explícitamente en mi ~/.ssh/configcon un alias corto para cada host. De esa manera no necesitaré usar ningún indicador de línea de comando y simplemente puedo escribir menos y usarlo ssh Destinationy terminar con él.
Host jumphost
Hostname jumphost.example.com
User serverfault
ForwardAgent yes
AddKeysToAgent yes
UseKeychain yes # Specific to OS X
IdentityFile ~/.ssh/id_rsa.jumphost
Host server1
Hostname server1.int.example.com
User hbruijn
ForwardAgent yes
AddKeysToAgent yes
UseKeychain yes # Specific to OS X
IdentityFile ~/.ssh/id_rsa.int.example.com
ProxyJump jumphost
ProxyJumpEs una configuración relativamente nueva que encuentro algo más intuitiva de usar que ProxyCommand. Ahora ssh server1hará exactamente lo que necesita: primero cree una sesión utilizando [email protected]como primer salto desde el cual realizará un túnel hasta el siguiente salto con, opcionalmente, una clave ssh diferente y un nombre de usuario diferente [email protected].
También puede utilizar el comando ProxyJump directamente desde la línea de comando:
ssh -J [email protected] [email protected]
Un enfoque diferente se analiza enestas preguntas y respuestas
Respuesta2
La solución canónica es implementar IPv6 (y/o una VPN) y evitar este tipo de solución para empezar, pero si no puede hacerlo hoy, entonces se llama jump box o host bastión o términos similares. Es solo una máquina que usted instala en la que sus usuarios pueden iniciar sesión con ssh y luego continuar con ssh en los hosts internos a los que esa caja tiene acceso a la red. El sshcomando incluso tiene una opción de línea de comando que automatiza la conexión a través del host de salto.
-J destination
Connect to the target host by first making a ssh connection to
the jump host described by destination and then establishing a
TCP forwarding to the ultimate destination from there. Multiple
jump hops may be specified separated by comma characters. This
is a shortcut to specify a ProxyJump configuration directive.
Note that configuration directives supplied on the command-line
generally apply to the destination host and not any specified
jump hosts. Use ~/.ssh/config to specify configuration for jump
hosts.