How a 30-year-old protocol lets you punch through firewalls, protect your traffic, and access anything, from anywhere
There's a feature baked into every SSH client on the planet that most developers use maybe once a year — if at all.
It's not glamorous. It doesn't have a flashy dashboard. But once you understand SSH tunneling, you'll wonder how you ever worked without it.
This article covers what SSH tunneling actually is, the three distinct types (and when to use each), real-world use cases that will make your day-to-day work easier, and the security implications you need to know.
No hand-waving. No "just trust me." Let's get into it.
What Is SSH Tunneling?
At its core, SSH tunneling — also called SSH port forwarding — is the act of routing arbitrary TCP traffic through an encrypted SSH connection.
You already know SSH as the thing you use to get a remote shell. But SSH isn't just a shell protocol. It's a full-blown encrypted transport layer. Once an SSH connection is established, you can piggyback other connections through it. Those connections inherit all the encryption and authentication of the parent SSH session.
Think of it like this: you've dug a secure, encrypted tunnel between two machines. Instead of just letting your terminal session run through it, you can route any network traffic through that same tunnel — database connections, web traffic, API calls, whatever you need.
The result: traffic that would otherwise be blocked, unencrypted, or exposed becomes secure and accessible.
The Three Types of SSH Tunnels
1. Local Port Forwarding (-L)
The most common type. Forwards a port on your local machine to a destination through the remote server.
ssh -L [local_port]:[destination_host]:[destination_port] [user]@[ssh_server]
Example:
What this does:
- Opens port
5432on your local machine - Any connection to
localhost:5432gets forwarded throughbastion.example.com
- Which then connects to
db.internal:5432(a host only the bastion can reach)
Your local machine acts as if the remote database is running locally. You can now run psql localhost:5432 from your laptop, even though the database is behind a private network.
When to use it:
- Accessing databases behind a firewall or bastion host
- Connecting to internal admin UIs (Kibana, Grafana, Kubernetes dashboard)
- Reaching development servers on a private subnet
- Bypassing network restrictions on corporate networks
2. Remote Port Forwarding (-R)
The reverse. Forwards a port on the remote server back to a destination accessible from your local machine.
ssh -R [remote_port]:[destination_host]:[destination_port] [user]@[ssh_server]
Example:
What this does:
- Opens port
8080onmyserver.com
- Any connection to
myserver.com:8080gets forwarded back through the SSH tunnel - Which then connects to
localhost:3000on your machine
You've just exposed your local development server to the internet through a remote server — without configuring your router, opening firewall ports, or touching NAT settings.
When to use it:
- Sharing a local dev server with a client or teammate
- Receiving webhooks (Stripe, GitHub, Slack) to a local server
- Giving remote access to a machine that's behind NAT
- Exposing local services temporarily without deploying
Note: By default, OpenSSH binds remote forwarded ports to
127.0.0.1only. To bind to all interfaces and make the port publicly reachable, addGatewayPorts yesto/etc/ssh/sshd_configon the remote server.
3. Dynamic Port Forwarding (-D)
Creates a SOCKS proxy. Instead of forwarding one port to one destination, all traffic through the proxy is routed via the SSH server — to any destination.
ssh -D [local_port] [user]@[ssh_server]
Example:
What this does:
- Opens a SOCKS5 proxy on your local machine at port
9999
- Any application configured to use this proxy routes its traffic through
myserver.com
- From the outside world's perspective, the traffic originates from the server, not you
Configure your browser to use SOCKS5 localhost:9999, and all your browsing traffic flows through the remote server's network.
When to use it:
- Browsing securely on untrusted public Wi-Fi
- Accessing geo-restricted content via a server in another region
- Routing specific application traffic through a known-safe exit point
- Quick VPN-like functionality without setting up a VPN
Real-World Use Cases
Access a Private Database Without a VPN
This is probably the most common use case in modern cloud infrastructure.
Your database lives in a private subnet — it has no public IP. To access it, you'd normally need a VPN connection to the VPC, which means IT tickets, credentials, and waiting.
Instead:
The -N flag tells SSH not to open a shell — just hold the tunnel open. Now connect your database GUI or CLI to localhost:5432 and you're in.
Works for PostgreSQL, MySQL, Redis, MongoDB — anything TCP.
Share Your Local Dev Server Instantly
Your designer needs to see the feature you're building. They're on the other side of the country. You don't want to deploy it yet.
Send them http://yourserver.com:8080. They see exactly what's running on your machine, live. No ngrok account needed, no tunneling service, no cost.
Receive Webhooks Locally
You're building a Stripe integration. You need webhooks to hit your local server at localhost:3000. Stripe can't reach that.
Point your Stripe webhook URL at http://yourserver.com:4567. Requests flow through the SSH tunnel directly to your local dev server.
Secure Your Traffic on Public Wi-Fi
At a coffee shop, airport, or hotel? The Wi-Fi is untrusted and potentially monitored.
The -f flag backgrounds the process. Configure your browser or system proxy to use SOCKS5 localhost:9999. All traffic is now encrypted through your SSH tunnel.
Access an Internal Web UI Without Touching VPN
Your Kubernetes dashboard, Grafana instance, or Elasticsearch UI runs on a private cluster. You don't want to expose it publicly, but you need access now.
ssh -L 9200:elasticsearch.internal:9200 \
-L 5601:kibana.internal:5601 \
-L 3000:grafana.internal:3000 \
-N [email protected]
One SSH command, three tunnels. Open localhost:5601 in your browser and Kibana loads — served privately from your internal cluster.
Keeping Tunnels Alive
By default, SSH connections drop when idle. For persistent tunnels, use these options:
ssh -L 5432:db:5432 \
-N \
-o ServerAliveInterval=60 \
-o ServerAliveCountMax=3 \
-o ExitOnForwardFailure=yes \
[email protected]
ServerAliveInterval=60— sends a keepalive every 60 seconds
ServerAliveCountMax=3— drops after 3 missed keepalives
ExitOnForwardFailure=yes— exits cleanly if the port can't be forwarded
For tunnels you always want running, use autossh:
sudo apt install autossh
autossh -M 0 -N \
-o "ServerAliveInterval 60" \
-o "ServerAliveCountMax 3" \
-L 5432:db.internal:5432 \
[email protected]
autossh monitors the connection and automatically restarts the tunnel if it drops.
Cleaner Tunnels With ~/.ssh/config
Stop typing long commands. Put your tunnels in ~/.ssh/config:
Host db-tunnel
HostName bastion.example.com
User ubuntu
IdentityFile ~/.ssh/id_ed25519
LocalForward 5432 db.internal:5432
LocalForward 6379 redis.internal:6379
ServerAliveInterval 60
ExitOnForwardFailure yes
Now this is all you need:
ssh -N db-tunnel
Security Considerations
SSH tunneling is powerful — which also means it can be misused or misconfigured. Here's what to keep in mind:
Tunnels bypass network controls
A tunnel routes traffic around firewalls, IDS systems, and network monitoring. In a corporate environment, this may violate policy. On your own infrastructure, it means a compromised SSH key could expose services you assumed were protected by network segmentation.
Restrict what can be forwarded on the server
In /etc/ssh/sshd_config on your SSH servers:
AllowTcpForwarding local # Only allow local forwarding (not remote)
GatewayPorts no # Don't expose forwarded ports publicly
PermitTunnel no # Disable full VPN-mode tunneling (tun devices)
Use AllowTcpForwarding no on servers where forwarding is never needed.
Scope your SSH keys
Use different keys for different purposes. A key that only needs to open a database tunnel doesn't need shell access. Use authorized_keys restrictions:
restrict,port-forwarding,permitopen="db.internal:5432" ssh-ed25519 AAAA... tunnel-key
This key can only forward to db.internal:5432. Nothing else.
Audit open tunnels
Check what's currently being forwarded:
ss -tlnp | grep ssh
Quick Reference
| Type | Flag | Direction | Best For |
|---|---|---|---|
| Local | -L local:dest:port | Local → Remote destination | Accessing private services |
| Remote | -R remote:local:port | Remote → Local destination | Exposing local services |
| Dynamic | -D port | All traffic via SOCKS proxy | Browsing, VPN-like usage |
The Bottom Line
SSH tunneling isn't a niche trick. It's a core skill that belongs in every developer and sysadmin's toolbox.
It handles use cases that would otherwise require a VPN, a third-party tunneling service, or a full infrastructure change — with nothing more than the SSH client you already have installed.
Master these three tunnel types, get comfortable with ~/.ssh/config, and you'll have a flexible, zero-cost solution for secure access in almost any situation.
The infrastructure is already there. Start using it.
If this helped, consider sharing it with your team. Follow for more practical deep-dives into the tools that power modern infrastructure.
SOCIAL SHARE CARD GENERATOR