Guía práctica de túneles SSH: reenvío de puertos local y remoto

Resumen general

• Los túneles SSH son una técnica para acceder de forma segura a servicios que no se pueden alcanzar directamente desde el exterior, o para exponer temporalmente servicios internos hacia afuera.
• El reenvío de puertos en SSH se divide principalmente en reenvío local, reenvío remoto, reenvío local dinámico y reenvío remoto dinámico.
• -L hace que el cliente SSH local abra un puerto, y -R hace que el servidor SSH remoto abra un puerto.
• Si se usa un Bastion Host, se puede conectar no solo al propio servidor SSH, sino también a otros servicios de red privada a los que ese servidor tenga acceso.
• El reenvío dinámico no fija un destino específico, sino que crea un proxy SOCKS para acceder a múltiples hosts y puertos.
• Para exponer el reenvío remoto a una red externa, es necesario revisar la configuración GatewayPorts del servidor SSH.

Introducción

Propósito de los túneles SSH

• SSH no solo permite ejecutar comandos remotos, también ofrece una función de túnel que transporta tráfico de red cifrado.

• Sin necesidad de una VPN independiente ni de un programa de proxy dedicado, es posible acceder a redes privadas y exponer servicios usando solo comandos estándar de SSH.

• Algunos casos de uso típicos son los siguientes.

  • Acceder a servicios internos de una VPC pasando por un servidor público
  • Abrir en el navegador de la PC del usuario un puerto local de un servidor remoto de desarrollo
  • Exponer temporalmente al exterior servicios del hogar o de una red privada
  • Conectar el puerto de depuración del navegador local a un agente remoto de desarrollo

• Al entender los túneles SSH, hay que distinguir estos dos puntos.

  • Qué equipo abre un nuevo puerto y queda a la espera
  • Desde la perspectiva de qué equipo se conecta el tráfico que pasa por el túnel a su destino

Desarrollo

El reenvío local conecta servicios remotos en tu entorno local

• El reenvío de puertos local conecta un servidor remoto, o un servicio accesible desde ese servidor remoto, a un puerto local de la PC del usuario.
• La estructura básica del comando es la siguiente.

ssh -L [local_addr:]local_port:remote_addr:remote_port [user@]sshd_addr  

• El cliente SSH espera conexiones en local_port de la PC del usuario.

• El tráfico que entra por ese puerto se envía a remote_addr:remote_port a través del túnel SSH.

• El destino final se alcanza desde la perspectiva de la red donde está ubicado el servidor SSH.

• Algunos casos de uso comunes son los siguientes.

  • Conexión a MySQL, PostgreSQL o Redis remotos
  • Acceso a aplicaciones web disponibles solo dentro de una red privada
  • Acceso a puertos de contenedores que no se han expuesto en la interfaz externa del servidor

Bastion Host actúa como intermediario para acceder a redes privadas

• remote_addr y sshd_addr, que es el destino de la conexión SSH, no tienen que ser el mismo equipo.

• Si el servidor SSH puede acceder a otros servicios internos, puede usarse como punto intermedio.

• A este tipo de servidor intermediario se le llama Bastion Host o Jump Host.

• Una estructura de conexión típica es la siguiente.

  • La PC del usuario se conecta por SSH a un Bastion Host público
  • El Bastion Host reenvía el tráfico a servicios internos dentro de la VPC a los que tiene acceso

• Esto permite conectarse a bases de datos, clústeres de búsqueda, APIs internas y otros servicios que no están expuestos al exterior.

El reenvío remoto expone servicios locales en el lado remoto

• El reenvío de puertos remoto conecta un servicio de la PC del usuario o de una red interna a un puerto del servidor SSH externo.
• La estructura básica del comando es la siguiente.

ssh -R [remote_addr:]remote_port:local_addr:local_port [user@]gateway_addr  

• El servidor SSH remoto abre remote_port y espera conexiones.

• El tráfico que entra por ese puerto se transmite, a través del túnel SSH, hacia local_addr:local_port del lado del cliente SSH.

• Algunos casos de uso comunes son los siguientes.

  • Exponer un servidor de desarrollo que corre en una laptop para una demo externa
  • Hacer accesibles desde internet servicios de un homelab
  • Proveer el puerto de depuración del navegador local a un entorno remoto de desarrollo

Para exponerlo al exterior se necesita la configuración de GatewayPorts

• En la configuración predeterminada, el puerto de reenvío remoto puede quedar enlazado solo a localhost del servidor SSH.
• En ese caso, se puede acceder al servicio desde dentro del servidor remoto, pero no desde el exterior.
• Para permitir el acceso mediante la IP pública del servidor remoto, es necesario revisar la siguiente configuración en sshd_config.

GatewayPorts yes  

• Como esta configuración puede exponer el puerto en interfaces externas, también deben aplicarse firewall y control de acceso.
• Si se expone un servicio de desarrollo directamente al internet público, puede aumentar el riesgo de accesos no autenticados o ataques.

El equipo local puede convertirse en un Jump Host de una red privada

• El destino del reenvío remoto no se limita al propio equipo donde corre el cliente SSH.

• Si la PC del usuario puede acceder a otro servidor dentro de la red doméstica, ese puerto del servidor interno también puede exponerse a través del servidor SSH remoto.

• En este caso, la PC del usuario se convierte en un equipo intermediario que conecta estas dos redes.

  • La red doméstica o una red privada de desarrollo
  • Un servidor gateway SSH con IP pública

• Esto permite acceder desde el exterior a servicios de un servidor doméstico o de un servidor interno de desarrollo que no están conectados directamente a internet.

El reenvío local dinámico crea un proxy SOCKS local

• El reenvío local normal fija un puerto local a un único destino.
• El reenvío local dinámico crea un proxy SOCKS en el cliente SSH.
• La estructura básica del comando es la siguiente.

ssh -D [local_addr:]local_port [user@]sshd_addr  

• En el puerto especificado de la PC del usuario se ejecuta un proxy SOCKS.

• Las aplicaciones compatibles con SOCKS pueden indicar una dirección y un puerto de destino distintos en cada conexión.

• La conexión al destino real se realiza desde la perspectiva de la red del servidor SSH remoto.

• A diferencia del reenvío local fijo, con una sola conexión SSH se puede acceder a varios servicios de la red privada remota.

• Algunos casos de uso comunes son los siguientes.

  • Llamadas a múltiples APIs internas a través de un Bastion Host
  • Exploración de aplicaciones web dentro de una red privada
  • Acceso a múltiples endpoints de una VPC a través de una sola instancia EC2

El reenvío remoto dinámico crea un proxy SOCKS remoto

• Si se omite el destino fijo en la opción -R, se puede crear un proxy SOCKS en el servidor SSH remoto.
• La estructura básica del comando es la siguiente.

ssh -R [bind_address:]port [user@]gateway_addr  

• El servidor gateway remoto espera conexiones SOCKS en el puerto especificado.
• Las solicitudes que entran al proxy se envían al lado del cliente a través del túnel SSH.
• El destino final se conecta desde la perspectiva de la red donde se encuentra el cliente SSH.
• Esto permite que, desde el servidor remoto, se pueda acceder a toda la red doméstica o red privada a la que tenga acceso la PC del usuario.
• El reenvío remoto dinámico requiere OpenSSH 7.6 o superior en el cliente.
• Para exponer el proxy SOCKS remoto en una interfaz externa, también se necesita la configuración GatewayPorts, igual que en el reenvío remoto normal.

Las opciones de ejecución en segundo plano mantienen solo el túnel

• Si quieres mantener solo el reenvío de puertos sin ejecutar un comando después de conectarte por SSH, usa la opción -N.
• Si además quieres enviar el túnel a segundo plano, puedes usar junto con ella la opción -f.
• Ejemplos por tipo.

ssh -f -N -L ...  
ssh -f -N -R ...  
ssh -f -N -D ...  

• En automatización o en entornos de operación prolongada, también conviene definir por separado cómo terminar el túnel, reconectar y detectar fallas.

Los comandos se distinguen por dónde abren el puerto

• ssh -L hace que el cliente SSH local abra un nuevo puerto.
• ssh -R hace que el servidor SSH remoto abra un nuevo puerto.
• ssh -D crea un proxy SOCKS en el cliente SSH local.
• ssh -R sin destino crea un proxy SOCKS en el servidor SSH remoto.
• La regla básica para recordar los comandos es la siguiente.

-L = local:remote  
-R = remote:local  

• La dirección y el puerto que están a la izquierda de los dos puntos son el punto de escucha que se abre nuevamente.
• local puede referirse al propio cliente SSH o a un equipo interno al que el cliente puede acceder.
• remote puede referirse al propio servidor SSH o a otro equipo interno al que el servidor puede acceder.

Conclusión

Los túneles SSH se eligen según la dirección de acceso

• Si quieres usar un servicio remoto desde tu PC, usa reenvío local -L.

• Si quieres exponer tu PC o un servicio interno hacia el lado del servidor remoto, usa reenvío remoto -R.

• Si necesitas acceder de forma flexible a múltiples destinos de una red remota, usa reenvío local dinámico -D.

• Si quieres que desde un gateway remoto se pueda acceder dinámicamente a toda la red del lado del cliente, usa reenvío remoto dinámico -R omitiendo el destino.

• Al diseñar un túnel SSH, primero hay que verificar estos puntos.

  • Dónde debe abrirse el nuevo puerto
  • Qué equipo puede alcanzar el destino final
  • La configuración de GatewayPorts, firewall y permisos de acceso SSH
  • Los riesgos de seguridad que puede implicar la exposición externa

• El criterio clave es de qué lado quieres que el servicio sea visible y qué equipo puede realmente alcanzar el destino.