SSH Port Forwarding Explained: Local, Remote, and Dynamic Tunnels

dpm_bush — Thu, 03 Sep 2026 04:39:35 +0000

SSH port forwarding — also called SSH tunneling — forwards traffic for another service through an already-encrypted SSH connection.

If you've ever needed to access a database that only listens on localhost, expose a local development server through a remote machine, or route an application's traffic through an SSH host, port forwarding is usually the simplest way to do it.

There are three types:

Type	Flag	What it does
Local forwarding	`-L`	Forwards a port on your machine through the SSH server to another destination
Remote forwarding	`-R`	Forwards a port on the SSH server back to your machine
Dynamic forwarding	`-D`	Turns the SSH connection into a SOCKS proxy

Let's look at each one.

What is SSH port forwarding?

A normal SSH connection:

ssh user@host

opens an interactive shell on the remote machine.

But SSH can carry more than terminal traffic over the same encrypted connection.

Port forwarding uses that connection to carry traffic from another service — for example:

a database connection
an internal web dashboard
a development server
application traffic through a SOCKS proxy

From the application's point of view, it usually connects to an ordinary local port. SSH handles transporting that traffic through the encrypted connection to its actual destination.

This is different from router port forwarding.

Router-level port forwarding changes NAT or firewall rules so incoming internet traffic reaches a device on a network.

SSH port forwarding happens entirely inside an existing SSH connection.

Local port forwarding with `-L`

Local forwarding is probably the most common type of SSH tunnel.

The syntax is:

ssh -L local_port:destination_host:destination_port user@ssh_server

Where:

local_port is the port opened on your machine
destination_host:destination_port is the destination as seen from the SSH server
user@ssh_server is the server carrying the tunnel

Example: connect to a remote MySQL database

Imagine MySQL is running on a server but only listening on localhost:3306.

Instead of exposing MySQL directly to the internet, create a tunnel:

ssh -L 3306:localhost:3306 deploy@db-host.example.com

Now point your local MySQL client at:

localhost:3306

Your client behaves as if MySQL were running locally.

In reality the path looks like this:

Your MySQL client
      |
localhost:3306
      |
      | SSH tunnel
      v
db-host.example.com
      |
localhost:3306
      |
     MySQL

The database port never needs to be publicly exposed. Only SSH does.

The same pattern works for Redis, internal dashboards, monitoring tools, and other services that aren't supposed to listen on a public interface.

A `localhost` gotcha

If the tunnel appears to work but your application hangs or gets refused, try 127.0.0.1 instead of localhost.

On some systems, localhost may resolve to the IPv6 loopback address ::1 first while the forward or destination service is listening only on IPv4.

Using 127.0.0.1 explicitly can avoid that mismatch.

Remote port forwarding with `-R`

Remote forwarding works in the opposite direction.

Instead of opening a port on your machine, it opens a port on the SSH server and forwards connections back through SSH to your local machine.

Syntax:

ssh -R remote_port:local_host:local_port user@ssh_server

Example: expose a local development server

Suppose you're running an application locally on port 3000:

localhost:3000

Create this tunnel:

ssh -R 8080:localhost:3000 user@ssh_server

Connections to port 8080 on the SSH server are now forwarded through the SSH connection to port 3000 on your machine.

The path is essentially:

SSH server :8080
      |
      | SSH tunnel
      v
Your machine :3000

By default, the remotely forwarded port is typically bound to loopback on the SSH server, meaning it can be reached from the server itself rather than automatically being exposed to the wider network.

This direction is also the foundation of an SSH reverse tunnel.

It's particularly useful when a machine:

has no public IP
sits behind NAT
sits behind a firewall
can make outbound SSH connections but can't accept inbound ones

For persistent reverse tunnels, there are additional things to consider such as GatewayPorts, restricted SSH keys, and automatic reconnection.

Dynamic port forwarding with `-D`

Local and remote forwarding both map a specific port to a specific destination.

Dynamic forwarding is different.

It turns SSH into a SOCKS proxy.

Start one with:

ssh -D 1080 user@ssh_server

SSH now exposes a SOCKS proxy on:

localhost:1080

Applications that support SOCKS can use that proxy and route their traffic through the SSH server.

For example:

curl -x socks5h://localhost:1080 https://example.com

Unlike -L, you don't specify one destination when creating the tunnel.

The application decides where it wants to connect, and the SSH server makes the outbound connection on its behalf.

This is useful when you want to:

access multiple internal services through a jump host
route one application's traffic through a remote server
make requests originate from a trusted network location
avoid creating a separate forward for every service

Keeping an SSH tunnel alive

A tunnel only exists while its SSH connection is alive.

A few options make tunnel-only connections more practical.

`-N`

Don't execute a remote command:

ssh -N -L 3306:localhost:3306 user@server

This is useful when the connection exists only for forwarding.

`-f`

Background SSH after authentication:

ssh -f -N -L 3306:localhost:3306 user@server

SSH keepalives

You can also make SSH detect dead connections:

ssh -f -N \
  -L 3306:localhost:3306 \
  -o ServerAliveInterval=30 \
  -o ServerAliveCountMax=3 \
  deploy@db-host.example.com

ServerAliveInterval=30 makes the client periodically send a message through the encrypted SSH connection.

ServerAliveCountMax=3 makes SSH exit after several unanswered messages.

One important distinction: this detects a dead connection. It does not reconnect automatically.

If you need an unattended tunnel that reconnects after failure, a tool such as autossh can handle the reconnect loop.

Put frequently used tunnels in `~/.ssh/config`

If you use the same tunnel regularly, you don't need to remember a giant command.

For example:

Host db-tunnel
  HostName db-host.example.com
  User deploy
  LocalForward 3306 localhost:3306
  ServerAliveInterval 30
  ServerAliveCountMax 3

Now:

ssh db-tunnel

opens the configured connection and forward.

The same SSH config can also contain options such as IdentityFile, ProxyJump, ports, usernames, and other per-host settings.

Is SSH tunneling secure?

The traffic inside an SSH tunnel inherits the encryption and authentication of the SSH connection.

But the way you expose the ends of the tunnel still matters.

Be careful with `GatewayPorts`

A remote forward created with -R normally isn't automatically exposed to everyone on the network.

Changing GatewayPorts can allow remotely forwarded ports to bind beyond loopback.

That can be intentional, but it can also expose a service much further than expected.

Prefer loopback when possible

There's an important difference between:

127.0.0.1

and:

0.0.0.0

A forwarded port bound to 127.0.0.1 is reachable only from the same machine.

Binding to 0.0.0.0 can make it reachable from other machines on the network as well.

Don't broaden the bind address unless you actually need to.

Close tunnels you no longer need

It's easy to create a tunnel for a quick task and forget about it.

A forgotten tunnel to a production database is still an access path.

Treat tunnels like any other connection to a sensitive service: know why they're running and close them when they're no longer needed.

SSH tunnel vs VPN vs exposing a port

These solve related problems, but they're not interchangeable.

	SSH tunnel	VPN	Public port
Scope	Usually one service, or selected app traffic with `-D`	Entire network	One publicly reachable service
Setup	Usually one SSH command	VPN server + client configuration	Firewall/NAT configuration
Best for	Reaching a few services through an SSH host	Ongoing access to a private network	Services intentionally designed to be public

If you're already SSHing into a server and just need access to one internal service, an SSH tunnel is often the fastest option.

If you need transparent access to an entire private network across multiple applications and devices, a VPN is usually the better tool.

The three commands worth remembering

If you forget everything else, remember these patterns.

Local forwarding:

ssh -L local_port:destination:port user@server

Remote forwarding:

ssh -R remote_port:local_destination:port user@server

Dynamic forwarding:

ssh -D local_port user@server

-L brings something reachable from the remote side to you.

-R makes something on your side reachable from the remote side.

-D gives applications a SOCKS proxy through the remote server.

Those three patterns cover most everyday SSH tunneling use cases.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

DEV Community: dpm_bush