Tus VPS hablando entre sí, sin abrir puertos a Internet

La forma habitual de que un VPS use la base de datos de otro es abrirle el puerto 5432 a Internet y confiar en la contraseña. Acá no hace falta: un VPS hace de receptor y otro de iniciador, y en unos clics el servicio privado del primero aparece en localhost del segundo. Nada queda expuesto, el túnel va cifrado por SSH, se reconecta solo y las claves se intercambian sin copiar y pegar.

  • Sin abrir puertos
  • Cifrado SSH
  • Se reconecta solo

Ver planes · Crear cuenta gratis

Así se ve en el panel

Capturas reales del panel de ArduMaker, no mockups.

Túneles SSH entre VPS: Túnel SSH entre dos VPS
Túnel SSH entre dos VPS. Iniciador con su clave y un túnel activo hacia una base privada.

El túnel SSH que siempre armabas a mano

Ahora con asistente, estado en vivo y las buenas prácticas puestas por defecto.

  • Receptor e iniciador: Cada VPS puede aceptar túneles, abrirlos, o las dos cosas a la vez. La topología la armás vos.
  • Nada expuesto a Internet: El servicio sigue escuchando solo en localhost del receptor. No se abre el 5432, ni el 3306, ni el 6379: el tráfico entra por el túnel o no entra.
  • Instalación en un clic: El receptor queda listo en segundos. El iniciador instala autossh solo, sin que toques un archivo de configuración.
  • Usuario de túnel restringido: El receptor crea un usuario dedicado sin contraseña, sin sudo y sin shell, que solo puede hacer port forwarding. Aunque alguien consiguiera la clave, no tiene dónde pararse.
  • Claves ed25519 que se registran solas: El iniciador genera su par de claves y el panel lo autoriza en el receptor, entre VPS de la misma empresa. Sin copiar y pegar, que es donde se cuelan los errores.
  • String de conexión listo: El receptor te da la cadena de conexión usando el DNS del VPS, así no tenés que repartir la IP por ahí.
  • Atajos para bases de datos: Sugerencias armadas para PostgreSQL (5432), MySQL (3306) y Redis (6379), que es el 90 % de los casos.
  • Siempre conectado: Cada túnel corre como servicio systemd con autossh: si se cae la red, vuelve solo. Y lo podés reiniciar desde el panel sin entrar por SSH.
  • Estado en vivo: Si el receptor está activo, si el puerto escucha, cuántos túneles hay y en qué estado está cada uno. Sin adivinar.
  • Cualquier puerto, no solo bases: Una API interna, un Elasticsearch, un panel de administración que no querés publicar: si escucha en un puerto, se puede tunelizar.

Asistente de 5 pasos

  1. Activá el receptor: En el VPS que tiene el servicio privado. Queda escuchando en el puerto 2222 con su usuario de túnel restringido.
  2. Activá el iniciador: En el VPS que va a consumir el servicio. Instala autossh y genera su par de claves ed25519.
  3. Registrá la clave: Un clic en el panel autoriza la clave pública del iniciador en el receptor. No hay que copiar y pegar nada.
  4. Creá el túnel: Elegís el puerto local del iniciador y el puerto de destino en el receptor. Para PostgreSQL, MySQL y Redis ya vienen sugeridos.
  5. Usalo en localhost: Tu app se conecta a localhost:5432 como si la base estuviera en la misma máquina. No hay nada que cambiar en el código más que el host.

Cómo funciona por debajo, y qué tener en cuenta

Lo que conviene saber antes de empezar, sin letra chica.

  • Es un port forwarding de SSH de toda la vida, pero armado y mantenido por el panel: el receptor corre un sshd con un usuario dedicado y el iniciador mantiene la conexión con autossh dentro de una unidad de systemd.
  • El usuario de túnel no tiene contraseña, ni sudo, ni shell. Su única capacidad es abrir port forwardings, así que una clave filtrada no da acceso al servidor.
  • El receptor usa el puerto 2222, que necesita tener su redirección activa. Es el único puerto que se abre, y no da shell a nadie.
  • El iniciador necesita salida a Internet para instalar autossh la primera vez. Después funciona igual aunque restrinjas la salida.
  • No se pueden repetir puertos locales entre túneles del mismo iniciador: si ya tenés el 5432 tomado por una base, la segunda va a otro puerto local.
  • Reinstalar el receptor genera un usuario de túnel nuevo. Hay que volver a autorizar las claves y recrear los túneles: no es un bug, es que la identidad anterior deja de existir.
  • Necesita systemd y una base Debian o Ubuntu. Está verificado en producción sobre Ubuntu 22.04 y es compatible con 24.04 y 26.04.
  • En Ubuntu 20.04 y anteriores no está disponible, y el motivo es concreto en cada caso: 16.04 trae OpenSSH 7.2, que no entiende la directiva Include y nunca lee sshd_config.d; el sshd_config de 18.04 directamente no incluye ese directorio; y en 20.04 la configuración base del VPS escribe KbdInteractiveAuthentication, que OpenSSH 8.2 no conoce, así que sshd -t falla y el cambio se revierte solo.
  • El túnel cifra el transporte, no autentica a tu aplicación: la base de datos sigue necesitando su usuario y su contraseña. Lo que desaparece es la exposición a Internet, no la autenticación.
  • Root real por SSH: el panel es un atajo, no una jaula. Todo lo que hace por botón también lo podés hacer a mano.

También se lo podés pedir a Claude, ChatGPT o Cursor

Todo lo que ves en el panel lo puede hacer tu agente de IA a través del servidor MCP de ArduMaker: con tu autorización, con el alcance que le des y con cada acción auditada. Ver qué hace el MCP

Túneles SSH entre VPS: preguntas frecuentes

¿Puedo usar la base de datos de otro VPS sin exponerla a Internet?

Sí, y es exactamente para lo que está. La base sigue escuchando solo en localhost del receptor; el puerto 5432 nunca se abre. En el VPS iniciador aparece en localhost a través del túnel cifrado, y tu app se conecta como si fuera local.

¿Cómo conecto dos servidores sin abrir puertos?

El único puerto que se abre es el 2222 del receptor, y atiende a un usuario sin shell que solo puede hacer port forwarding. Los servicios que querés compartir —la base, Redis, una API interna— no se publican: viajan dentro del túnel SSH.

¿Tengo que copiar claves SSH a mano?

No. El iniciador genera su par ed25519 y el panel registra la clave pública en el receptor con un clic, entre VPS de la misma empresa. Es el paso donde más errores se cometen cuando se hace a mano.

¿Qué pasa si se corta la conexión?

Cada túnel corre con autossh dentro de una unidad de systemd, así que se reconecta solo cuando la red vuelve. También lo podés reiniciar desde el panel sin entrar por SSH.

¿Un VPS puede ser receptor e iniciador al mismo tiempo?

Sí. Es lo normal cuando tenés tres o cuatro servidores hablando entre sí: cada uno ofrece algo y consume algo.

¿Sirve para algo que no sea una base de datos?

Para cualquier cosa que escuche en un puerto. Un Elasticsearch, una API interna, un panel de administración que no querés publicar, un servicio de colas. Las bases solo vienen con los puertos sugeridos porque son el caso más frecuente.

¿Es lo mismo que una VPN como Tailscale o WireGuard?

Resuelve un problema parecido con menos piezas. Una VPN te arma una red entre las máquinas y todo lo que escuche queda alcanzable dentro de ella; un túnel SSH publica un puerto puntual en otra máquina y nada más. Si lo que necesitás es que una app llegue a una base, el túnel es más simple y no agrega un demonio de red.

¿El túnel hace que mi base sea segura?

Cifra el transporte y saca la base de Internet, que es la mitad importante. La otra mitad sigue siendo tuya: la base necesita igual su usuario y su contraseña, porque el túnel no autentica a tu aplicación.

¿Por qué no funciona en Ubuntu 20.04?

Porque la configuración base del VPS escribe KbdInteractiveAuthentication, una directiva que OpenSSH 8.2 no conoce: sshd -t falla y el cambio se revierte. En 18.04 el problema es otro, que sshd_config no incluye sshd_config.d, y en 16.04 que OpenSSH 7.2 no entiende Include. Está verificado en 22.04 y es compatible con 24.04 y 26.04.

¿Cuánto cuesta?

Nada aparte del VPS. Los túneles SSH vienen en el panel de todos los planes, incluido el más chico.

Servicios que suelen ir juntos

Todo corre en el mismo VPS y se maneja desde el mismo panel.

  • PostgreSQL: Instalás PostgreSQL y administrás bases, usuarios y permisos sin línea de comandos.
  • Redis: Instalás Redis, ajustás memoria y persistencia, y buscás, editás y borrás claves desde el panel.
  • Gestor de bases de datos: Una grilla web para PostgreSQL y MySQL: editar filas, SQL, EXPLAIN e importar y exportar CSV y Excel por túnel privado.

Arquitectura de varios servidores, sin la parte difícil Túneles SSH incluidos en el panel de cada VPS, en todos los planes. No es un producto aparte: está en el panel de cualquier VPS de ArduMaker, junto al root real por SSH. Ver planes

Cómo funciona por dentro

La documentación técnica de lo que hay en esta página: qué hace cada herramienta, qué cambia, cómo se verifica y qué herramientas MCP la operan.

  • Túneles SSH: Túnel SSH persistente entre dos VPS con autossh: un servicio del receptor queda en localhost del iniciador sin exponerse.

Toda la documentación