SSH Tunnel for PostgreSQL: connect without opening port 5432
Published on 2026-10-26 by frfrand
Secure remote access to Postgres via ssh -L on a VPS
You want to open PostgreSQL from DBeaver on your laptop, but the database runs on a VPS and should not listen on the Internet. An SSH tunnel forwards a local port to the server without publicly opening PostgreSQL's 5432.
Let's turn this into a procedure you can use on a real VPS. The goal is to understand why it works, how to test it, and what problem appears if one part is misconfigured.
What an SSH Tunnel for PostgreSQL Means and When You Need It
With ssh -L, the client opens a port on your machine and sends connections to a destination seen from the SSH server. PostgreSQL authentication is still required; the tunnel does not turn anyone into a database user.
Before changing anything in production, note the current state: IP, domain, port, affected service, and time of the last deploy. An isolated modification is easy to verify; five simultaneous changes make it harder to reconstruct what happened.
Configuration or Example Commands
# 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 15432Domains, IP addresses, paths, and names are illustrative. Do not copy an entire configuration over the current one without comparing first. In examples that include ports or firewall settings, make sure to preserve administrative access.
How I Would Do It Step by Step
- Preparation. Leave PostgreSQL listening on localhost or on a suitable internal interface.
- Step 2. Check SSH access with an authorized individual account.
- Step 3. Open the tunnel and verify that port 15432 is only available locally.
- Step 4. Connect with a PostgreSQL user with minimal permissions.
- Verification. Close the tunnel when finished and check the logs if access fails.
When you are done, verify the actual operation from another connection. For example, for an API it is not enough to open the browser: run a read request, a write to a test database, and check the process logs.
Example of a real project
A freelancer needs to review a reservation from a tours platform in production. They open a temporary tunnel and query the database with a read-only user, without exposing 5432 to the world or sharing the administrator's password.
The lesson is simple: an infrastructure configuration does not live isolated from the application. The frontend, the server, the database, and the workers connect, so measuring where the failure starts is more useful than restarting everything.
The mistake to avoid
If the database is on another host, the destination of ssh -L is resolved from the SSH endpoint. A tunnel does not replace backups, engine authentication, or access policies. Do not confuse it with opening a public tunnel.
When working with client servers, keep a backup or rollback procedure before changes that affect data, network, or certificates. And if you don't know what permissions an operation needs, avoid running it as root just to stop errors from showing up.
How does it relate to ArduMaker?
In ArduMaker you can manage VPS and PostgreSQL; for remote maintenance access, an authorized SSH connection can be much more secure than directly publishing the database port.
In a typical case you can create a VPS for the application, deploy from Git, associate an HTTPS domain, and manage the backend and the necessary databases. The tools help centralize operations, but you need to understand which port and process fulfills each function.
Questions that come up when you try it
How do I know if the failure is DNS or the service? Check resolution first, then the connection to the port, and finally the application response. That order avoids confusing different problems.
Can I expose a database to make maintenance easier? Better design private access or authenticated tunnels when possible. Exposing a port does not replace engine permissions or the firewall.
What should I document? The expected configuration, how it is verified, and how to return to the previous state. That document helps you more than a list of commands without context.
References
In summary: a good network or server configuration is one that you can explain, verify, and recover when something fails.