Túnel SSH y reenvío de puertos: guía práctica

Un túnel SSH transporta conexiones TCP dentro de una sesión SSH cifrada. Sirve para alcanzar un servicio interno sin publicarlo directamente, ofrecer temporalmente un servicio local a un sistema remoto o crear un proxy SOCKS. La elección depende de dónde debe escuchar el puerto y quién puede conectarse.

El límite importante aparece donde termina SSH. El tramo entre su equipo y el servidor SSH va protegido por la sesión; la conexión desde ese servidor hasta el destino puede viajar por otra red y usar su propio cifrado, o no usarlo. Un túnel no vuelve segura una aplicación insegura por arte de magia.

Tampoco es una VPN ligera. El reenvío mueve las conexiones que usted declara o que una aplicación envía al proxy. No cambia automáticamente las rutas de todo el sistema, no protege cada protocolo y no concede permiso para atravesar redes ajenas.

Use los ejemplos únicamente en infraestructura propia o administrada con autorización. Antes de abrir nada, confirme la clave del host SSH por un canal fiable, el servicio de destino, la dirección de escucha y la política del servidor.

El modelo mental: escucha, canal y destino

Cada reenvío tiene tres piezas. Primero hay un socket de escucha que acepta una conexión. Después, SSH transporta esa conexión por su canal cifrado. Por último, uno de los extremos abre una conexión TCP hacia el destino real.

La pregunta útil no es qué letra recuerda, sino dónde se abre el puerto y desde qué máquina se ve el destino. Si esas dos respuestas no están claras, la orden puede funcionar y aun así exponer el servicio al equipo equivocado.

Reenvío local con -L: traer un servicio interno a su equipo

El reenvío local abre la escucha en la máquina donde ejecuta el cliente SSH. Cuando una aplicación se conecta a ese puerto local, el tráfico cruza la sesión y el servidor SSH intenta alcanzar el destino desde su propia red.

Este patrón encaja para administrar una base de datos, un panel o una API que solo acepta conexiones desde una red privada. El servicio permanece sin puerto público; usted necesita acceso SSH a un host que sí pueda verlo.

Un ejemplo con nombres y puertos de documentación sería:

ssh -N -T \
  -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:15432:db.internal.example:5432 \
  admin@bastion.example.net

La dirección inicial limita la escucha al loopback de su equipo. El primer puerto es el que usa su aplicación local. El nombre y el último puerto identifican el destino visto desde el servidor SSH. Sustitúyalos por valores aprobados de su infraestructura.

Las opciones de sesión evitan ejecutar un comando remoto y desactivan el pseudoterminal. La comprobación de fallo hace que el cliente termine si no logra crear la escucha solicitada. No garantiza que el destino final esté disponible más tarde: una base de datos caída seguirá rechazando conexiones.

Aquí aparece una confusión frecuente. El nombre interno no tiene que resolverse desde su portátil; lo resuelve o utiliza el lado remoto al abrir la conexión final. Esto permite acceder a nombres privados, pero también significa que el servidor SSH conoce el destino solicitado.

Reenvío remoto con -R: llevar un servicio local al otro extremo

El reenvío remoto invierte el punto de entrada. La escucha se crea en el servidor SSH. Cuando alguien autorizado se conecta allí, el canal vuelve hacia su cliente y la conexión al destino final se abre desde su equipo.

Puede servir para mostrar temporalmente una aplicación local a un proceso de integración en el servidor o para una intervención de soporte acordada. No es una puerta trasera legítima por llevar SSH: la autorización debe existir antes del túnel y el acceso debe retirarse al terminar.

Una forma conservadora mantiene la escucha remota en loopback:

ssh -N -T \
  -o ExitOnForwardFailure=yes \
  -R 127.0.0.1:18080:127.0.0.1:8080 \
  admin@gateway.example.net

El servicio remoto queda accesible solo desde el propio servidor SSH mientras la política lo permita. Desde allí, la conexión cruza el canal y llega al servicio que escucha en su equipo. Compruebe además que ese servicio local espera solicitudes de ese origen y aplica su propia autenticación.

Pedir una dirección no local cambia el riesgo. El servidor puede aceptar o rechazar ese bind mediante GatewayPorts, y el administrador puede limitar reenvíos con AllowTcpForwarding, PermitListen y PermitOpen. Que el cliente solicite una exposición no obliga al servidor a concederla.

Si varias máquinas deben entrar, no improvise una escucha global. Defina quién necesita acceso, limite la red en el cortafuegos, mantenga autenticación en la aplicación y acuerde con el administrador la política de SSH. Una escucha amplia convierte una herramienta puntual en superficie de ataque.

Reenvío dinámico con -D: un proxy SOCKS, no una ruta total

La modalidad dinámica abre un proxy SOCKS local. La aplicación entrega a ese proxy el destino de cada conexión; SSH transporta la petición y el lado remoto conecta con el destino elegido. Es útil cuando hay varios servicios TCP y la aplicación sabe hablar SOCKS.

ssh -N -T \
  -o ExitOnForwardFailure=yes \
  -D 127.0.0.1:1080 \
  admin@bastion.example.net

Después hay que configurar explícitamente el navegador, cliente HTTP u otra herramienta compatible. Las demás aplicaciones continúan usando sus rutas normales. Protocolos distintos de TCP, procesos que ignoran el proxy y tráfico del sistema no entran automáticamente en este canal.

La resolución DNS merece una prueba aparte. Resolver localmente y delegar el nombre no son equivalentes. Algunas aplicaciones envían al proxy una dirección; otras le entregan el nombre. En curl, la modalidad SOCKS5 normal resuelve localmente, mientras la variante que conserva el nombre deja la resolución al proxy.

Eso no es solo privacidad. Un nombre interno quizá solo exista en el DNS visto desde el servidor SSH. Si se resuelve en su equipo, fallará o consultará a un resolvedor que no debía conocerlo. Revise la documentación de cada aplicación: decir usa SOCKS no determina por sí solo dónde se resuelve DNS.

La dirección de bind decide quién encuentra la puerta

Escuchar en loopback restringe el punto de entrada a procesos de la misma máquina. Para una herramienta administrativa suele ser el valor sensato. Escuchar en todas las interfaces, en cambio, permite que otros equipos intenten conectarse si la red y el cortafuegos lo permiten.

No confunda ese bind con el destino. En un reenvío local, la dirección inicial gobierna quién llega al puerto de su equipo; el host posterior indica qué intenta alcanzar el lado remoto. En un reenvío remoto, la dirección inicial pertenece al servidor y queda sometida a GatewayPorts y a las restricciones de sshd.

Antes de ejecutar, escriba la ruta en una línea: cliente que entra → dirección que escucha → servidor SSH → destino que sale. Pregunte por el tráfico en ese orden. Si no sabe qué equipos pueden tocar la escucha, todavía no está listo para abrirla.

Verifique la identidad del servidor antes de confiarle tráfico

El cifrado solo ayuda si está conectado al servidor correcto. OpenSSH conserva las claves de host conocidas y avisa cuando una identidad cambia. Verifique la huella inicial con el administrador o con un inventario fiable; ante un cambio inesperado, investigue antes de aceptar.

No resuelva una advertencia desactivando StrictHostKeyChecking ni borrando entradas a ciegas. El cambio puede ser una reinstalación prevista, pero también un error de DNS, un host equivocado o una interceptación. Una automatización madura distribuye claves conocidas o certificados de host y falla de forma visible ante discrepancias.

La autenticación del usuario es otra capa. Una clave autorizada permite iniciar la sesión según la cuenta y la política, pero no sustituye la autorización sobre la base de datos, el panel o el servicio reenviado. Mantenga credenciales y controles de aplicación en el destino.

Compruebe el túnel desde ambos extremos

Una sesión SSH abierta no demuestra que la ruta completa funcione. Confirme primero que el puerto escucha solo en la dirección prevista. Después pruebe el servicio con su cliente real y revise desde qué máquina ve la conexión el destino.

Si falla, separe el diagnóstico:

• Si no se crea la escucha, busque un puerto ocupado, permisos locales o una denegación de la política SSH.
• Si la escucha existe pero el destino no responde, compruebe nombre, ruta, cortafuegos y proceso desde el lado que abre la conexión final.
• Si SOCKS conecta por dirección pero no por nombre, pruebe dónde resuelve DNS la aplicación.
• Si otro equipo alcanza una escucha que debía ser local, cierre el túnel y corrija el bind antes de continuar.

El modo verboso del cliente ayuda a distinguir autenticación, creación del forward y apertura de canales. No publique esos registros sin revisarlos: pueden contener nombres internos, cuentas y detalles de red.

Cerrar también forma parte del diseño

Para una sesión en primer plano, detenga el proceso SSH y confirme que el puerto deja de escuchar. Si usa multiplexación, cancele el reenvío correspondiente o cierre el maestro mediante el mecanismo de control documentado. No mate procesos al azar en un servidor compartido.

Evite dejar túneles manuales como infraestructura invisible. Si el acceso debe ser permanente, conviértalo en un servicio administrado con propietario, cuenta restringida, política de reinicio, registros, límites de destino y revisión periódica. Un proceso olvidado también es una dependencia olvidada.

Para una intervención temporal, registre quién la autorizó, qué origen puede entrar, qué destino queda alcanzable y cuándo debe retirarse. Al acabar, cierre la sesión, verifique la escucha y retire cualquier regla de cortafuegos temporal.

Elegir sin memorizar recetas

Use reenvío local cuando usted necesita traer un servicio remoto o interno a su máquina. Use reenvío remoto cuando un proceso del lado del servidor necesita alcanzar algo disponible desde su equipo. Use reenvío dinámico cuando aplicaciones compatibles necesitan elegir varios destinos mediante SOCKS.

En los tres casos, mantenga la escucha tan estrecha como sea posible y trate el destino como un servicio independiente, con autenticación y cifrado propios cuando corresponda. El canal SSH es una ruta controlada, no una absolución de la arquitectura.

La decisión concreta cabe en dos preguntas: ¿dónde debe estar la puerta y desde qué lado se ve el servicio? Si además puede explicar quién la autorizó y cómo se cierra, ya tiene un túnel operable, no un agujero con una letra delante.