Túnel SSH para PostgreSQL: conectarte sin abrir el puerto 5432
Publicado el 2026-10-26 por frfrand
Acceso remoto seguro a Postgres mediante ssh -L en un VPS
Querés abrir PostgreSQL desde DBeaver en tu portátil, pero la base corre en un VPS y no debería escuchar en Internet. Un túnel SSH reenvía un puerto local hacia el servidor sin abrir públicamente el 5432 de PostgreSQL.
Vamos a convertirlo en un procedimiento que puedas usar en un VPS real. El objetivo es entender por qué funciona, cómo probarlo y qué problema aparece si una parte queda mal configurada.
Qué significa Túnel SSH para PostgreSQL y cuándo lo necesitás
Con ssh -L, el cliente abre un puerto en tu máquina y envía conexiones a un destino visto desde el servidor SSH. La autenticación de PostgreSQL sigue siendo necesaria; el túnel no convierte a cualquiera en usuario de base de datos.
Antes de cambiar nada en producción, anotá el estado actual: IP, dominio, puerto, servicio afectado y hora del último deploy. Una modificación aislada es fácil de comprobar; cinco cambios simultáneos hacen más difícil reconstruir lo ocurrido.
Configuración o comandos de ejemplo
# En tu laptop: puerto local 15432 hacia Postgres del VPS
ssh -N -L 127.0.0.1:15432:127.0.0.1:5432 usuario@vps.ejemplo.com
# En otra terminal
psql 'host=127.0.0.1 port=15432 dbname=app user=lector'
# O en DBeaver: host 127.0.0.1, port 15432Los dominios, IP, rutas y nombres son ilustrativos. No copies una configuración entera encima de la actual sin comparar primero. En los ejemplos que incluyen puertos o firewall, asegurate de conservar el acceso administrativo.
Cómo lo haría paso a paso
- Preparación. Dejá PostgreSQL escuchando en localhost o en una interfaz interna adecuada.
- Paso 2. Comprobá acceso SSH con una cuenta individual autorizada.
- Paso 3. Abrí el túnel y verificá que el puerto 15432 sólo está disponible localmente.
- Paso 4. Conectate con un usuario PostgreSQL de permisos mínimos.
- Verificación. Cerrá el túnel al terminar y revisá los logs si el acceso falla.
Cuando termines, comprobá la operación real desde otra conexión. Por ejemplo, para una API no alcanza con abrir el navegador: ejecutá una petición de lectura, una escritura en una base de prueba y consultá los logs del proceso.
Ejemplo de un proyecto de verdad
Un freelance necesita revisar una reserva de una plataforma de tours en producción. Abre un túnel temporal y consulta la base con un usuario de sólo lectura, sin exponer 5432 al mundo ni compartir la contraseña del administrador.
La lección es sencilla: una configuración de infraestructura no vive aislada de la aplicación. El frontend, el servidor, la base de datos y los workers se conectan, así que medir dónde empieza el fallo es más útil que reiniciar todo.
El error que evitaría
Si la base está en otro host, el destino de ssh -L se resuelve desde el extremo SSH. Un túnel no sustituye backups, autenticación del motor ni políticas de acceso. No lo confundas con abrir un túnel público.
Cuando trabajás con servidores de clientes, guardá un respaldo o procedimiento de reversión antes de cambios que afecten datos, red o certificados. Y si no sabés qué permisos necesita una operación, evitá ejecutarla como root sólo para que deje de mostrar errores.
¿Cómo se relaciona con ArduMaker?
En ArduMaker podés administrar VPS y PostgreSQL; para acceso remoto de mantenimiento, una conexión SSH autorizada puede ser mucho más segura que publicar directamente el puerto de la base.
En un caso típico podés crear un VPS para la aplicación, desplegar desde Git, asociar dominio HTTPS y administrar el backend y las bases necesarias. Las herramientas ayudan a centralizar operaciones, pero hay que entender qué puerto y proceso cumple cada función.
Preguntas que aparecen cuando lo probás
¿Cómo sé si el fallo es de DNS o del servicio? Consultá primero la resolución, después la conexión al puerto y finalmente la respuesta de aplicación. Ese orden evita confundir problemas diferentes.
¿Puedo exponer una base para que sea más fácil mantenerla? Mejor diseñá acceso privado o túneles autenticados cuando sea posible. Exponer un puerto no reemplaza los permisos del motor ni el firewall.
¿Qué debería documentar? La configuración esperada, cómo se comprueba y cómo volver al estado anterior. Ese documento te ayuda más que una lista de comandos sin contexto.
Referencias
En resumen: una buena configuración de red o servidor es la que podés explicar, verificar y recuperar cuando algo falla.