Muchas empresas utilizan servidores de salto accesibles Secure Shell (SSH) para acceder a sistemas críticos para el negocio. Los administradores primero se conectan a un servidor de salto mediante SSH, posiblemente a través de una VPN, antes de conectarse al sistema de destino. Este método generalmente funciona muy bien siempre que un administrador se ciña a la administración de línea de comandos. Se vuelve un poco más complicado cuando un administrador quiere salirse del ámbito de la línea de comandos y usar una interfaz basada en web en su lugar.
Veamos el siguiente escenario:Bob es administrador de sistemas en Securecorp y acaba de recibir una alerta que indica que un clúster de base de datos consiste en sirius.securecorp.io. y orion.securecorp.io se está desempeñando mal. Para un análisis inicial, suele utilizar la consola web RHEL8. El cortafuegos no le permite conectarse directamente a este sistema desde su estación de trabajo, pero puede pasar por un servidor de salto llamado bastion.securecorp.io. .
[ También puede disfrutar de: 6 guías esenciales de SSH para administradores de sistemas ]
El acceso de la línea de comandos SSH al clúster de la base de datos es sencillo:
[bob@workstation ~]$ ssh bastion.securecorp.io
[bob@bastion ~]$ ssh sirius.securecorp.io
[bob@sirius ~]$
[bob@workstation ~]$ ssh bastion.securecorp.io
[bob@bastion ~]$ ssh orion.securecorp.io
[bob@orion ~]$ Pero, ¿y si Bob quiere acceder a la consola web RHEL8 de sirius.securecorp.io? y orion.securecorp.io ? Hay varias formas de lograr este objetivo mediante SSH, todas ellas relacionadas con el reenvío de puertos de algún tipo.
Descargo de responsabilidad :En algunas organizaciones, las políticas de seguridad no permiten el reenvío de puertos. Para asegurarse de no infringir ninguna regla, consulte con su representante de seguridad de TI.
Reenvío de puertos SSH
Usando SSH, Bob abre un túnel TCP para ambos sistemas, apuntando al puerto de la consola web (9090) para sirius.securecorp.io y puerto 9091 para orion.securecorp.io .
[bob@workstation ~]$ ssh -L 9090:sirius.securecorp.io:9090 bastion.securecorp.io
[bob@bastion ~]$
[bob@workstation ~]$ ssh -L 9091:orion.securecorp.io:9090 bastion.securecorp.io
[bob@bastion ~]$ Bob ahora puede dirigir el navegador de su estación de trabajo local a https://localhost:9090 para acceder a la consola web de sirius.securecorp.io y https://localhost:9091 para acceder a la consola web de orion.securecorp.io .
Este enfoque podría funcionar bien en ciertos casos, pero tiene sus limitaciones:
- Validación del certificado TLS:el navegador local no está contento porque, en la mayoría de los casos, el nombre común del certificado no coincide con el nombre de host en la barra de direcciones (localhost), por lo que la validación del certificado falla.
- Redirecciones:cuando el sitio web al que accede lo redirige a otra URL, la conexión falla porque el reenvío de puertos solo es válido para este servidor web. Esta situación podría ser un problema al usar el inicio de sesión único (SSO), por ejemplo.
Inicie un navegador en el servidor de salto
Bob también debería iniciar un navegador como Firefox en el servidor de salto y mostrarlo localmente en su estación de trabajo. SSH proporciona una función llamada reenvío X, que se puede utilizar en esta situación.
[bob@workstation ~]$ ssh -X bastion.securecorp.io
[bob@bastion ~]$ firefox https://sirius.securecorp.io:9090 &
[bob@bastion ~]$ firefox https://orion.securecorp.io:9090 & Con este método, el proceso del navegador se ejecuta en el servidor de salto y las conexiones a las consolas web de sirius.securecorp.io y orion.securecorp.io están permitidos. Solo la representación de la ventana del navegador ocurre en la estación de trabajo de Bob.
Si bien este enfoque resuelve algunos problemas del reenvío de puertos SSH simple, también tiene limitaciones:
- Rendimiento:este método generalmente funciona bastante mal porque la salida gráfica debe transferirse desde el servidor de salto a la estación de trabajo a través de la red, lo cual es muy ineficiente.
- Requisitos previos:se debe instalar un navegador como Firefox en el servidor de salto y se debe ejecutar un servidor X en la estación de trabajo.
Ingrese el reenvío de puerto dinámico
Habiendo explorado los dos enfoques anteriores y aprendido acerca de sus desventajas, sería genial tener una tercera opción, que nos trae lo mejor de ambos mundos:
- Se puede utilizar el navegador de la estación de trabajo.
- La conectividad y la resolución de nombres DNS deben ser las mismas que en el servidor de salto.
Para lograr esto, SSH proporciona una función llamada reenvío de puertos dinámicos , que aprovecha el protocolo SOCKS. En esta configuración, SSH actúa como un proxy SOCKS, retransmitiendo todo el tráfico relevante a través de la conexión SSH. Para que esto suceda, el cliente (en nuestro ejemplo, es el navegador) debe ser compatible con SOCKS.
Bob puede iniciar una sesión SSH con reenvío de puerto dinámico de la siguiente manera:
[bob@workstation ~]$ ssh -D 1080 bastion.securecorp.io
[bob@bastion ~]$ Después de eso, el navegador de la estación de trabajo de Bob debe estar preparado para SOCKS. La configuración de Firefox se puede lograr así:
- Apunte el navegador a about:preferences.
- En el General pestaña, desplácese hacia abajo en la parte inferior y haga clic en Configuración... en la Configuración de red sección.
- En la Configuración de conexión ventana, elija Configuración de proxy manual , especifique localhost para anfitrión de SOCKS , 1080 como Puerto y seleccione SOCKS v5 .
- En la misma ventana, seleccione Proxy DNS cuando use SOCKS v5 .
Bob ahora puede dirigir el navegador a https://sirius.securecorp.io:9090 y https://orion.securecorp.io:9090 para analizar los problemas de rendimiento de sus dos servidores de base de datos utilizando la consola web RHEL8. También puede acceder a cualquier otro recurso interno como si el navegador se estuviera ejecutando en bastion.securecorp.io .
Nota :El puerto 1080 es el puerto registrado por IANA para SOCKS, pero la conexión puede usar cualquier otro puerto. Los números en el SSH y la configuración del navegador deben coincidir.
Personalmente, encontré útil crear un perfil de navegador separado para que no sea necesario cambiar constantemente entre configuraciones de proxy. Se puede crear un nuevo perfil pasando -P cambia a firefox comando, iniciando el Administrador de perfiles . Llamé a mi perfil Jump . Después de crear un nuevo perfil, se crea una configuración vacía. En este perfil, apliqué la configuración como se describe arriba y dejé intacto mi perfil predeterminado.
Después de crear el perfil, se puede iniciar Firefox con el siguiente comando:
[bob@workstation ~]$ firefox -P Jump
Otro consejo útil es crear una configuración específica de host para el reenvío dinámico de puertos en su ~/.ssh/config expediente. Por ejemplo:
[bob@workstation ~]$ cat ~/.ssh/config
Host bastion
Hostname bastion.securecorp.io
User bob
DynamicForward 1080 [ Un curso gratuito para usted:Resumen técnico de virtualización y migración de infraestructura. ]
Resumir
Hay muchas formas de conectarse a sistemas internos mediante un servidor de salto y las posibilidades descritas anteriormente no son exhaustivas. Sin embargo, en mi experiencia, SSH le brinda un conjunto de herramientas muy poderoso, que en la mayoría de los casos está disponible y listo para funcionar sin muchos obstáculos. El reenvío de puertos dinámico es una de estas herramientas y me ha ayudado a ser más productivo en situaciones específicas, así que pruébalo tú mismo.