The syntax for local, remote, and dynamic forwarding is similar enough that it's easy to mix them up. But you don't need to memorize three unrelated commands. The useful question is simpler:

Where does the connection begin, and where should the traffic end up?

Once that direction is clear, -L, -R, and -D become much easier to reason about.

What an SSH tunnel actually does

A normal SSH connection gives you an encrypted, authenticated connection to another machine:

ssh user@server

SSH can carry more than an interactive shell over that connection. Port forwarding uses the same encrypted channel to carry traffic for another service.

That can be useful when a database, internal dashboard, Redis instance, or development service should not be exposed directly to the public internet. Your application talks to a port, while SSH moves that traffic through the encrypted connection to its actual destination.

This is different from router port forwarding. Router forwarding changes NAT or firewall rules for inbound traffic. SSH forwarding happens inside an existing SSH connection.

Local forwarding: -L

Use local forwarding when you are on your machine and need to reach something available from the remote side.

The general form is:

ssh -L local_port:destination_host:destination_port user@ssh_server

For example, imagine MySQL is running on a remote server on port 3306, but the database only listens locally and isn't exposed to the internet.

You can create this tunnel:

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

Then point your local database client at:

localhost:3306

Your client behaves as if MySQL were running locally. In reality, traffic goes through SSH to db-host.example.com, where it reaches port 3306.

The important part is that MySQL itself never needs a public port.

The same pattern works for Redis, internal admin panels, monitoring dashboards, and other services reachable from the SSH server.

A useful shortcut is:

-L means I need a local port that reaches something on the remote side.

If you run into a loopback mismatch, explicitly using 127.0.0.1 instead of localhost can also help on systems where localhost resolves to IPv6 first while the service or forward is listening only on IPv4.

Remote forwarding: -R

Remote forwarding reverses the direction.

Use it when something on the remote side needs a path back to a service on your machine.

The syntax is:

ssh -R remote_port:local_host:local_port user@ssh_server

Suppose you're running a development server locally:

localhost:3000

You can make it reachable from the SSH server through port 8080:

ssh -R 8080:localhost:3000 user@ssh_server

Connections to that forwarded port travel backward through the SSH connection and reach your local service on port 3000.

This is why -R is commonly used for reverse SSH tunnels. It's useful when the machine hosting a service has no convenient inbound route — for example, when it's behind NAT or a firewall — but it can still establish an outbound SSH connection.

By default, a remote-forwarded port is typically bound to loopback on the SSH server. Making it reachable beyond the server itself can involve SSH server settings such as GatewayPorts, along with firewall and network configuration.

So -R does not automatically mean "make my local service public."

The mental model is:

-R means the remote side gets a port that leads back to me.

Dynamic forwarding: -D

Dynamic forwarding solves a different problem.

With -L and -R, you choose a fixed destination in advance. With -D, SSH creates a SOCKS proxy:

ssh -D 1080 user@ssh_server

That gives you a SOCKS proxy on:

localhost:1080

An application that supports SOCKS can then choose its own destinations while sending traffic through the SSH server.

For example:

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

This makes -D useful when you want selected application traffic to travel through a trusted SSH host without creating a separate tunnel for every destination.

A simple way to remember it:

-D = dynamic destination.

The three flags in one view

The commands may look similar:

# Local forwarding
ssh -L 3306:localhost:3306 user@server

# Remote forwarding
ssh -R 8080:localhost:3000 user@server

# Dynamic forwarding
ssh -D 1080 user@server

But they answer different questions:

• -L — I need to reach something through the SSH server.

• -R — the SSH server side needs a path back to something on my side.

• -D — my application should choose destinations dynamically through a SOCKS proxy.

That's the part worth remembering. The syntax is much easier once the direction makes sense.

Run a tunnel without opening a shell

If the tunnel is the only reason you're connecting, you don't need an interactive remote shell.

Use -N:

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

-N tells SSH not to execute a remote command.

You can also use -f to background the SSH process after authentication:

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

For connections that may stay idle, SSH keepalives can help detect a dead connection:

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

One distinction matters: keepalives help SSH notice that a connection has died. They do not automatically reconnect the tunnel after SSH exits.

Put repeated tunnels in SSH config

If you use the same tunnel regularly, moving it into ~/.ssh/config is cleaner than keeping a long command around.

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

Now the tunnel can be opened with:

ssh db-tunnel

That is easier to maintain and much harder to mistype.

Pay attention to what the forwarded port exposes

SSH encrypts the tunnel, but that doesn't automatically make every forwarding configuration safe.

The bind address matters.

A forwarded port bound to:

127.0.0.1

is available only from that machine.

A port bound to:

0.0.0.0

can potentially be reached from other machines, depending on firewall and network rules.

That distinction is especially important with remote forwarding. Changing settings such as GatewayPorts can make a forwarded service reachable beyond the SSH server itself.

Sometimes that's exactly what you need. Other times it turns a private database or development service into something exposed much more broadly than intended.

Also close tunnels you no longer need. A forgotten tunnel is still an access path to the service behind it.

The practical rule

Don't start by asking, "Was remote forwarding -L or -R?"

Start with the traffic direction.

If you're sitting on your machine and need access to something reachable from the server, use -L.

If the remote side needs a path back to something running on your machine, use -R.

If an application needs to choose multiple destinations through the SSH host, use -D.

Once you think about SSH forwarding that way, the flags stop feeling arbitrary.

I keep a more reference-oriented version with additional examples, configuration notes, and security details in my SSH port forwarding guide on SSHFlow