SSH Port Forwarding with a Terminal Client: -L -R -D
One SSH session can carry a device's web UI, a database port, or a whole SOCKS proxy, all encrypted and without opening the firewall.
SSH is not only a shell. Its forwarding features turn a single encrypted session into a tunnel that carries other TCP services, which is how engineers reach a device's web interface that has no public address or sits behind a restrictive network.
This article explains the three forwarding modes, local (-L), remote (-R), and dynamic (-D), and when each is the right tool for reaching equipment from a terminal client.
Local forwarding (-L)
Local forwarding opens a port on your own machine and sends anything sent to it through the SSH session to a destination the server can reach. The classic case is a device web UI reachable only from the SSH server's network: you map a local port to the device, then browse to your own localhost.
The destination is expressed from the server's point of view. If the server can reach the device at an internal address, your local port reaches it too, with the traffic encrypted between you and the server.
- Use it to: Reach a device UI or service that only the SSH server can see.
- Bind: A local port you then point a browser or client at.
- Scope: The path is you -> SSH server -> target.
Remote forwarding (-R)
Remote forwarding is the inverse: it opens a port on the SSH server and sends traffic from there back to a destination on your side. It is how you expose a local service to someone on the server's network, or reach a device that lives on your side from the server.
This is useful but needs care: you are opening a listener on a machine you may not own outright. Restrict the bound address and confirm the server permits remote forwards before relying on it.
Caution: Remote forwarding places a listening port on the server. Keep it scoped and remove it when the task is done so it does not linger.
Dynamic forwarding (-D)
Dynamic forwarding turns the session into a SOCKS proxy. Instead of mapping one port to one destination, the client routes whatever traffic you point at the proxy through the server, deciding the destination per connection.
This is the tool for reaching several internal services without setting up a forward for each. Point an application's SOCKS setting at the local proxy port and its connections exit from the server's network.
Choosing the right mode
Pick local forwarding for a known single service behind the server, such as one device's HTTP port. Pick remote forwarding when the service you need is on your side and the server's side must reach it. Pick dynamic forwarding when you need to reach many destinations ad hoc through one session.
A common mistake is opening more forwards than needed. Each extra tunnel is another path through the firewall, so map only what the job requires and close them after.
| Mode | Listener on | Reaches | Typical use |
|---|---|---|---|
| -L local | Your machine | Server-side target | Device web UI behind server |
| -R remote | SSH server | Your-side target | Expose local service to server net |
| -D dynamic | Your machine (SOCKS) | Any, per connection | Ad-hoc multi-service access |
Keeping tunnels trustworthy
Forwarding inherits the same host verification as the SSH session, so a confirmed known_hosts entry matters before you trust a tunnel. Combine forwarding with key authentication so the tunnel comes up without a password and without weakening the link.
Watch for forwarded ports left open after the task. A tunnel that nobody remembers is a forgotten path into a network; close the session or remove the forward when the work is finished.
Treat each forward as a change to the security boundary and note it the way you would note a firewall rule. If a reviewer asks 'why is this port open', a one-line reason attached to the session answers it. Tunnels opened for convenience and never closed are how small, justified exceptions become standing holes.
Set up key authentication so tunnels open without passwords, apply the pattern from the network engineer SSH guide, and prefer this over cleartext Telnet for legacy gear.
Try it on your own files
Download the free trial and see how it behaves on real work.
Download More articlesCommon questions
What is the difference between -L and -R?
Local (-L) opens a port on your machine that reaches a server-side target. Remote (-R) opens a port on the SSH server that reaches a target on your side. They are mirror images of each other.
When should I use dynamic forwarding?
Use -D when you need to reach several internal services through one session without configuring a separate forward for each. It acts as a SOCKS proxy that decides the destination per connection.
Is the forwarded traffic encrypted?
Yes. The traffic between you and the SSH server is encrypted as part of the SSH session; the destination sees it as coming from the server, not directly from you.
Why can't I reach the device through my local forward?
Check that the destination address is expressed from the server's perspective and that the server itself can reach the device. Also confirm the local port is not already taken by another service.
Should I leave forwards open after the task?
No. Each open forward is a path through the firewall. Close the session or remove the forward when the work is done so it does not linger as an unused entry point.