El comando ssh esconde tres herramientas de red distintas detrás de una sola bandera -L/-R/-D. Con ellas conviertes cualquier servidor SSH en un puente cifrado hacia servicios privados: bases de datos sin exposición pública, paneles internos, APIs de desarrollo. Es la navaja suiza más infravalorada del oficio, y funciona sin instalar nada en el servidor — ya lo tienes.
El modelo mental: un túnel entre dos puntos
Todo port forwarding SSH sigue el mismo principio: tu cliente SSH abre un puerto de escucha en uno de los extremos, y todo lo que entra por ahí viaja dentro del canal cifrado SSH hasta salir por el otro extremo hacia el destino indicado. La conexión intermedia cruza internet cifrada; solo los tramos locales (tu app → ssh; ssh → destino) son tráfico plano dentro de máquinas confiables.
Tres direcciones posibles, tres modos:
Local forwarding (-L): traer un servicio remoto a ti
El más usado. Escenario típico: PostgreSQL corriendo en tu VPS, escuchando solo en localhost porque jamás debe exponerse a internet. Necesitas conectar con DBeaver desde tu portátil:
ssh -L 5433:localhost:5432 usuario@miservidor.es
Sintaxis: -L <puerto_local>:<destino_visto_por_el_servidor>:<puerto_destino>. Ahora localhost:5433 en tu máquina ES la base de datos remota. Conéctate con cualquier cliente a localhost:5433.
Detalle que confunde al principio: el destino se resuelve desde la perspectiva del servidor. Ese localhost:5432 es el localhost del servidor. Por eso puedes alcanzar servicios que solo escuchan en su loopback — y también destinos terceros (-L 8080:intranet.interna:80) donde el servidor actúa de saltador hacia su red privada.
Añade -N cuando no quieras shell, solo túnel, y -f para mandarlo a background:
ssh -fN -L 5433:localhost:5432 usuario@miservidor.es
Remote forwarding (-R): exponer tu máquina local
La dirección invertida: un puerto abierto en el servidor redirige hacia tu equipo. El caso estrella: mostrar al cliente o a un webhook externo lo que corre en tu portátil.
# En tu máquina:
ssh -R 9000:localhost:3000 usuario@miservidor.es
Ahora https://miservidor.es:9000 (o tras proxy) sirve tu localhost:3000 — el webhook de Stripe puede golpearlo aunque tu portátil esté detrás de NAT. Alternativas modernas para este caso: ngrok, Cloudflare Tunnel — pero SSH lo hace gratis y sin terceros cuando ya tienes VPS.
Dos configuraciones necesarias en el servidor para que esto funcione bien: GatewayPorts yes si el puerto debe escuchar en todas las interfaces (no solo loopback), y tener presente que expones temporalmente tu entorno de desarrollo — cierra el túnel al terminar.
Dynamic forwarding (-D): el proxy SOCKS
El modo más potente: en lugar de mapear puertos concretos, tu cliente SSH abre un proxy SOCKS5 local que enruta cualquier destino bajo demanda:
ssh -D 1080 -C -N usuario@miservidor.es
Configura navegador o sistema para usar SOCKS5 → localhost:1080 y todo tu tráfico de navegación sale desde el servidor. Es tu VPN improvisada para redes hostiles (hotel, coworking): cifrado hasta tu VPS y salida con su IP. A diferencia de los modos anteriores, no necesitas saber antes qué puertos usarás — el túnel decide mirando cada petición.
Firefox permite configurar proxy solo para él (mejor higiene que enrutar el sistema entero); activa además network.proxy.socks_remote_dns para que también las consultas DNS viajen por el túnel y evites fugas.
Seguridad e higiene
Los túneles heredan la seguridad de SSH — claves Ed25519, sin contraseñas, como cubrimos en la guía de claves — pero añaden sus propias reglas:
- Permisos finos en servidores compartidos:
AllowTcpForwardingen sshd_config puede limitarse o desactivarse por usuario si solo algunos deben tunelar. - Bind address: por defecto
-Lescucha solo en tu loopback (correcto).-L 0.0.0.0:5433:...abriría el puerto a tu red local — hazlo solo conscientemente. - Keepalive para conexiones largas:
ServerAliveInterval 60evita que NAT y firewalls maten el túnel inactivo. - Auto-reconexión: autossh (o systemd service con Restart=always) mantiene túneles críticos vivos ante cortes.
# ~/.ssh/config
Host tunel-db
HostName miservidor.es
User miguel
LocalForward 5433 localhost:5432
ServerAliveInterval 60
ExitOnForwardFailure yes
Con esa config, ssh -N tunel-db y punto: los alias convierten comandos kilométricos en dos palabras.
Casos de uso del día a día
Acceder al panel de administración de una app Dockerizada que solo escucha internamente, depurar webhooks contra desarrollo local, saltar un firewall corporativo saliendo por tu VPS, administrar routers/impresoras de la oficina remota sin VPN formal, proteger sesiones de gestión mientras viajas. Un patrón, veinte problemas resueltos.
Preguntas frecuentes
¿SSH tunneling o VPN? Para acceder a 2-3 servicios concretos, túnel SSH: cero infraestructura. Para equipos enteros con muchos protocolos y rutas, VPN real (WireGuard). No compiten: escalas distintas.
¿Por qué mi túnel se cae cada pocos minutos? Casi siempre NAT/firewall cerrando conexiones inactivas. ServerAliveInterval 30-60 lo resuelve; si la red es agresiva, baja a 15.
¿Se puede tunelar UDP? No nativamente — SSH transporta TCP. Para UDP hay trucos con socat en ambos extremos, pero a ese punto monta WireGuard y olvídate.
Genera las claves para tus túneles con nuestro generador de claves SSH, directamente en tu navegador.