Reaching private services safely with an SSH tunnel

You need to reach a database, dashboard, or admin page on your server, but you do not want to leave the front door wide open to the internet.

Short version: An SSH tunnel lets you access a private service through your normal SSH login, as if the service were running on your own computer. It is useful when PostgreSQL, Redis, an internal dashboard, or another tool should stay hidden from the public web but still be reachable by you. The service remains private; the tunnel acts like a temporary, locked hallway from your laptop to the server.

What is an SSH tunnel?

An SSH tunnel is a safe path inside an SSH connection. SSH is the secure remote login system many people use to manage a server. A tunnel uses that same encrypted connection to carry traffic for another service.

Think of your server like a building. The website is the shop window on the street. SSH is the staff entrance with a key. A private database is a room in the back that customers should never see.

An SSH tunnel lets you walk through the staff entrance and reach the back room without adding a new public door to the building.

In practical terms, your laptop gets a local address such as localhost:15432. When you connect to that local address, SSH quietly forwards the traffic to a private service on the server, such as PostgreSQL on 127.0.0.1:5432. The important detail is that PostgreSQL does not need to listen on the public internet.

That is the core idea behind using an ssh tunnel to access service safely: the service stays private, and your access travels through SSH.

When should you use an SSH tunnel to access a service?

Use an SSH tunnel when a tool needs your eyes, but not the whole internet.

Common examples include database tools like PostgreSQL, MySQL, or MariaDB. You might want to inspect data from your laptop using a desktop app, but you do not want port 5432 or 3306 open to everyone.

It also fits admin dashboards. Maybe you have a queue monitor, metrics page, staging app, search console, or internal panel. These are useful, but they often were not designed to be public websites.

Docker makes this pattern common. A container might expose a service only to the server itself, while you reach it through a tunnel when needed. If containers are still a fuzzy topic, our plain-English guide to Docker on a server gives the wider picture.

The rule of thumb is simple: if only you or a small team need the service, and it does not need to serve public visitors, keep it private and reach it through SSH.

Is an SSH tunnel safer than opening a port?

Usually, yes. Opening a port means telling the internet that a service exists and is ready to receive traffic. Sometimes that is necessary, as with a public website on ports 80 and 443. For private tools, it is often unnecessary risk.

An SSH tunnel keeps the private service behind the wall and uses SSH as the controlled entry point. That does not make the server magically safe. Your SSH access still needs strong keys, sensible user permissions, and a firewall. But it greatly reduces the number of things exposed to strangers.

A firewall is still part of the picture. It is the bouncer that decides which doors exist from the outside. If you have not set one up yet, start with how to set up a firewall on your server.

The safer pattern is not secrecy for its own sake. It is fewer public doors, fewer surprise scans, and fewer services that need to defend themselves directly.

What can go wrong with SSH tunnels?

The most common problem is mixing up the two sides of the tunnel. There is a local port on your laptop, and there is a destination host and port on the server. If you picture it like mail forwarding, your laptop is the temporary mailbox, and the server service is the real address.

Another common mistake is binding the service publicly by accident. A database listening on 0.0.0.0 may accept connections from the network, depending on firewall rules. A database listening on 127.0.0.1 accepts only local connections from the server itself, which is usually what you want for a tunnel.

Port conflicts also happen. If your laptop already has something using localhost:5432, your tunnel may need a different local port, such as localhost:15432. The number on your laptop does not have to match the number on the server.

Then there is the human problem: three months later, nobody remembers which local port pointed to which service, why it was private, or whether it was safe to expose. That confusion is how temporary fixes turn into permanent risk.

If the issue looks more like visitors cannot reach a public site at all, that is a different layer of networking. This guide on why a website is not loading explains the public side.

FAQ

Can I use an SSH tunnel for a database? Yes. PostgreSQL, MySQL, and MariaDB are common uses. The database can stay private while your local database app connects through SSH.

Does an SSH tunnel require a domain name? No. It uses SSH access to the server. A domain can be convenient, but an IP address also works.

Is an SSH tunnel the same as a VPN? No. A VPN usually joins networks together. An SSH tunnel usually forwards one service or port through one SSH connection.

Should I leave an SSH tunnel running all the time? Only if you need it. For many admin tasks, it is better as a temporary path you open, use, and close.

The shortcut

Server Manager helps you keep private services private without turning your setup into a puzzle. The outcome is that a database, dashboard, or internal tool does not need a public port just because you want to inspect it from your laptop.

It also helps avoid the messy failures this post described: opening a database to the internet by accident, losing track of which port belongs to which project, or letting one small admin tool become a permanent public door. The real benefit is that the setup remains understandable later, when you come back and need to know what is exposed and what is not.

That matters most after the first successful connection. A safe private service is not just reachable today; it is still legible months from now.

What does a safe private service setup feel like?

A good SSH tunnel setup feels boring in the best way. Your public website stays public. Your private services stay private. You can reach what you need without giving every scanner on the internet a new target.

You get the practical win: access when you need it, fewer open doors when you do not, and a server setup you can still understand later.