termalQuieres entrar por SSH a una máquina a la que no puedes abrir conexiones de entrada: un servidor de casa tras tu router, una Raspberry Pi en la oficina, una máquina en un enlace móvil o 5G. La respuesta de siempre —reenviar el puerto 22 en el router— cada vez está menos disponible, y donde lo está, es mala idea. Este artículo recorre los cuatro enfoques que funcionan de verdad, qué te cuesta cada uno y un ejemplo resuelto de cada cual. Ninguno abre un puerto de entrada en la máquina a la que llegas.
Por qué ya no basta con reenviar un puerto
Dos cosas se interponen. Primero, el NAT de operador (CGNAT): la mayoría de conexiones domésticas de fibra, cable, móvil y Starlink comparten hoy una sola IP pública entre muchos clientes, así que no hay ningún puerto en «tu» dirección que reenviar —el router que controlas no es el que tiene la IP pública—. Segundo, incluso con una IP pública real, un puerto SSH reenviado lo encuentran los escáneres en minutos; los logs se llenan de intentos de fuerza bruta desde el momento en que se expone. La solución en todos los casos de abajo tiene la misma forma: la máquina privada hace una conexión de salida hacia algo alcanzable, y tú entras montado en esa conexión. La salida funciona incluso a través de CGNAT y firewalls cerrados, porque no es más que otra conexión que sale de la red.
Las cuatro opciones de un vistazo
| Enfoque | Qué ejecutas | Infraestructura extra | ¿Clave de larga duración en la máquina? | Ideal para |
|---|---|---|---|---|
| Túnel SSH inverso | ssh -R + autossh en la máquina | un VPS con IP pública | sí (hacia el VPS) | ya alquilas un VPS |
| VPN de malla (Tailscale / WireGuard) | un cliente VPN en ambos extremos | un servicio de coordinación | tu clave SSH normal | llegar a varias máquinas |
| Cloudflare Tunnel | cloudflared en la máquina | una cuenta de Cloudflare + dominio | tu clave SSH normal | ya usas Cloudflare |
| Connector de salida | un agente pequeño en la máquina | una cuenta de Termalin | no — certificado de corta duración | acceso desde el navegador, sin VPS ni VPN |
Las tres primeras te dan un ssh you@… normal desde tu portátil. La última llega a la máquina desde un navegador o un agente de IA en su lugar. Sigue leyendo para ver cuál encaja.
Opción 1 — Túnel SSH inverso a través de un VPS
Si ya alquilas un VPS barato con IP pública, la máquina privada puede marcar hacia él y reenviar su propio puerto SSH de vuelta. En la máquina tras NAT:
ssh -N -R 2222:localhost:22 tunnel@vps.example.comEso abre el puerto 2222 en el VPS y canaliza cada conexión a él de vuelta al puerto 22 de la máquina de casa. Desde cualquier parte, salta a través del VPS para aterrizar en la máquina:
ssh -J tunnel@vps.example.com -p 2222 you@localhostUn ssh -R pelado muere la primera vez que la red tiene un hipo, así que envuélvelo en autossh bajo una unidad de systemd para mantenerlo vivo entre reinicios y caídas, y añade -o ServerAliveInterval=30 -o ExitOnForwardFailure=yes. La mecánica completa —incluido el detalle de GatewayPorts y por qué el túnel se ata al loopback del VPS por defecto— está en túneles SSH inversos, explicados. Contrapartida: estás manteniendo un VPS y una clave de larga duración en la máquina que puede llegar a él, y ese VPS pasa a formar parte de tu superficie de ataque.
Opción 2 — Una VPN de malla (Tailscale o WireGuard)
En vez de exponer un puerto, pon ambas máquinas en una red privada que solo ellas vean. Tailscale es la versión de poco esfuerzo. En la máquina tras NAT:
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale upInstala Tailscale también en tu portátil y ambos obtienen una dirección 100.x.y.z estable (y un nombre MagicDNS). Entonces es tan simple como:
ssh you@home-boxcomo si estuvieras en la misma LAN —la máquina nunca queda expuesta a la internet pública en absoluto—. sudo tailscale up --ssh puede incluso encargarse de la autenticación SSH por ti, así que no gestionas claves para ella. WireGuard es la misma idea hecha a mano: tú mismo ejecutas la coordinación y configuras los peers a mano —más trabajo, sin coordinador de terceros—. Para un laboratorio casero con un NAS y un par de Pis, una VPN de malla suele ser la respuesta entera, y es la opción por defecto a la que recurro en la guía del NAS/servidor de casa. Contrapartida: cada dispositivo que necesite acceso tiene que unirse a la red, lo que supone un cliente que instalar y una cuenta que mantener.
Opción 3 — Cloudflare Tunnel
Si tu dominio ya está en Cloudflare, cloudflared te da un túnel de salida sin puerto abierto. En la máquina:
cloudflared tunnel login
cloudflared tunnel create homeEnruta un nombre de host al túnel y apúntalo al sshd local (ssh://localhost:22) en la configuración del túnel, luego ejecuta cloudflared como servicio. Del lado del cliente, SSH llega a él a través de un ProxyCommand en tu ~/.ssh/config (en inglés):
Host ssh.example.com
ProxyCommand cloudflared access ssh --hostname %hAhora ssh you@ssh.example.com fluye a través del edge de Cloudflare hasta la máquina. El plan gratis lo cubre. Contrapartida: estás enrutando tu SSH por un tercero y tomando una dependencia de una cuenta de Cloudflare y un dominio que alojas ahí —genial si ya lo haces, excesivo si no—.
Opción 4 — Un Connector de salida (sin VPS, sin VPN)
Las tres opciones de arriba piden cada una infraestructura permanente: un VPS, una VPN o un dominio en Cloudflare. El Connector de Termalin lo reduce a un solo comando y llega a la máquina desde tu navegador, la app de Termalin o un agente de IA en vez de con un ssh local. En el servidor privado, una línea instala un pequeño agente estático (Linux x86_64 y arm64):
curl -fsSL https://termal.in/tunnel-install.sh | sudo TERMALIN_TOKEN=<token> shEl agente marca hacia fuera a Termalin por un único WebSocket y lo mantiene abierto; nunca escucha en un puerto. Cuando abres una terminal en el cliente web, la petición baja por ese enlace y el agente se conecta al propio sshd de la máquina en localhost —solo mueve bytes SSH opacos, así que nunca ve tus credenciales ni el texto plano de la sesión—. El alta hace que el sshd de la máquina confíe en la autoridad de certificación SSH de Termalin, de modo que los inicios de sesión usan un certificado de corta duración en lugar de una clave privada de larga duración posada en el servidor. Esa es la única fila de la tabla con un «no» bajo clave de larga duración en la máquina.
El pero, dicho sin rodeos: llegas a la máquina a través del lado alojado de Termalin —la terminal web, las apps de escritorio y de iOS de Termalin (que conectan por la misma pasarela), o un agente de IA a través del servidor MCP— no con un comando ssh crudo desde tu propia máquina, y el Connector es parte del plan de pago (o de la prueba). Si lo que quieres es una terminal normal desde tu portátil, las opciones 1–3 encajan mejor. Si lo que quieres es acceso desde el navegador en cualquier dispositivo —o dejar que un agente trabaje en una máquina que no tiene dirección pública ni clave que robar—, esta es la opción hecha para ello. El mismo Connector de salida también lleva monitorización ligera y alertas a una máquina sin puerto abierto.
¿Cuál deberías elegir?
- Ya alquilas un VPS: el túnel inverso lo reaprovecha —un
ssh -Rbajo autossh y listo. - Tienes más de una máquina a la que llegar, o quieres que se sientan como una LAN: una VPN de malla como Tailscale escala mejor y no expone nada.
- Tu dominio vive en Cloudflare: su túnel encaja de forma natural sin ningún proveedor nuevo.
- Quieres cero infraestructura permanente, acceso desde el navegador o acceso supervisado de agentes: un Connector de salida, sin ninguna clave de larga duración posada en el servidor.
Las cuatro comparten el único principio que vale la pena recordar: nunca abras un puerto de entrada en una máquina que no puedas permitirte que escaneen. Deja que ella salga en su lugar —esa simple inversión de sentido es lo que hace seguro el SSH tras NAT.
Termalin es un cliente SSH gratis y multiplataforma con túneles guardados, una terminal web y un Connector sin claves para servidores privados — descárgalo, o mira cómo maneja tus claves de forma segura.