Túneles SSH

¿Qué permite hacer?

• Usar desde un VPS un servicio que escucha en otro (una base, una API interna) como si estuviera en localhost, sin publicarlo en internet.
• Armar todo en una sola llamada (configurar_tunel_entre_vps), o paso a paso.
• Autorizar o revocar las claves que pueden entrar al receptor.
• Arrancar, detener o reiniciar cada túnel, y ver su estado en vivo.

¿Cuándo conviene usarlo?

• Una app en un VPS necesita la base de datos que vive en otro.
• Separar una API interna de su frontend sin abrir puertos públicos del servicio.

¿Cómo funciona en ArduMaker?

Es un reenvío local (ssh -L) que corre en el iniciador: lo que escucha en puerto_remoto del receptor queda disponible en localhost:puerto_local dentro del iniciador. No funciona al revés y no expone nada a internet.

Los pasos

1. Receptor (configurar_receptor_tunel_vps): crea un usuario dedicado al túnel, configura sshd para aceptar ese usuario en el puerto 2222 (sin terminal, sin X11, sin agente, solo reenvío TCP) y publica el 2222 con una redirección. Corre en segundo plano.
2. Iniciador (configurar_iniciador_tunel_vps): instala autossh y genera un par de claves ed25519. También en segundo plano.
3. Clave: la clave pública del iniciador se autoriza en el receptor (agregar_clave_receptor_tunel_vps).
4. Túnel (crear_tunel_vps): crea en el iniciador un servicio systemd ardutunnel_<nombre> que corre autossh -L <local>:<destino>:<puerto> contra el receptor, lo habilita y lo arranca.

configurar_tunel_entre_vps hace los cuatro pasos y además arranca el túnel. Espera a que cada rol termine de instalarse (hasta unos minutos); si uno no termina a tiempo, se detiene con tunel_rol_instalando y se puede retomar con desde. Un rol ya instalado no se reinstala, una clave ya autorizada se reusa y un túnel con ese nombre y puerto local ya creado se devuelve tal cual.

¿Qué cambia realmente?

En el receptor

• Un usuario de túnel con sus claves autorizadas en un bloque propio de authorized_keys.
• Un archivo de configuración de sshd gestionado por ArduMaker que agrega el puerto 2222 con su bloque Match LocalPort (el 22 sigue declarado). No hay que editarlo a mano: se reescribe entero cada vez que cambia un rol.
• Una redirección pública hacia el 2222 del VPS.

En el iniciador

• El paquete autossh y un par de claves ed25519 del usuario de túnel.
• Un servicio ardutunnel_<nombre>.service por túnel, con Restart=always, habilitado al inicio.
• Un known_hosts propio de los túneles: la primera clave del receptor queda fijada y, si después cambia, el túnel no conecta.

Puertos y conexión

ExecStart=/usr/bin/autossh -M 0 -N \
  -o "ServerAliveInterval=30" -o "ServerAliveCountMax=3" \
  -o "StrictHostKeyChecking=accept-new" -o "ExitOnForwardFailure=yes" \
  -L <puerto_local>:localhost:<puerto_remoto> \
  -i <clave_del_tunel> -p <public_port> <usuario>@<dnsip>

ver_estado_receptor_tunel_vps devuelve la cadena de conexión y un ejemplo de uso para conectar desde otra máquina con ssh -N -L.

Esquema

Resultado esperado

• ver_tunel_vps muestra el túnel con el estado en vivo de su servicio systemd.
• listar_tuneles_vps lista los túneles del iniciador; ver_estado_iniciador_tunel_vps trae su clave pública y la cantidad de túneles.
• Desde el iniciador, el servicio responde en localhost:<puerto_local>.

systemctl status ardutunnel_mi-base
nc -vz localhost 15432

Errores y resolución

Si un paso del flujo falla, se deshace lo que se puede; los paquetes instalados quedan y se informan en residuo (reinstalar no cambia nada). El flujo acepta idempotency_key y simular.

Relación con MCP

Sí, en los perfiles /mcp y /mcp/vps. Instalar un rol devuelve un operacion_id: ver_operacion dice cuándo está listo.

Referencia en /mcp/docs y ejemplos en /mcp/tuneles.

Funciones relacionadas

• Firewall y puertos
• Servicios systemd
• PostgreSQL
• Servidores VPS