SSH BridgeSSH Bridge
<- Back to SSH Academy

SSH Tunneling

Local vs Remote Forwarding

Choose the correct forwarding direction for your access problem.

Short answer

Local vs Remote Forwarding is about carrying traffic through an encrypted SSH connection so a private service can be reached without opening it directly to the internet. Choose the correct forwarding direction for your access problem.

What you will learn

  • Local forwarding
  • Remote forwarding
  • Decision rules

Why this matters

Local vs Remote Forwarding is powerful because it lets teams reach private services without publishing them directly. It is also risky when people forget that a tunnel is still network exposure.

Access a private database, dashboard, or development service through a server you already trust.
Debug remote systems without permanently exposing extra ports to the public internet.
Create temporary access paths for support, migration, or incident response.
Route traffic through a known SSH identity instead of sharing raw service credentials.

How it works

An SSH tunnel carries traffic through an encrypted SSH session. One side listens on a port, and SSH forwards that traffic to a destination from the perspective of the local machine, remote server, or dynamic SOCKS proxy.

Local forwarding is common for private databases and dashboards. Remote forwarding is useful when a private machine needs to expose something through a reachable server. Dynamic forwarding creates a SOCKS proxy for more flexible traffic routing.

The operational question is not only whether the tunnel works. It is who can use the listening port, how long it should stay open, and whether the access path is logged or reviewed.

Practical example

The exact command or configuration depends on your operating system and security policy, but this pattern is a useful starting point for understanding the workflow.

ssh -L 8080:localhost:80 [email protected]
ssh -R 8080:localhost:3000 [email protected]

Always test examples in a non-critical session first. SSH server settings can lock you out if authentication, firewall, DNS, or host key state is not understood.

Production checklist

Bind forwarded ports to localhost unless other machines truly need to connect.
Name and document long-lived tunnels so teammates know what service they expose.
Prefer short-lived tunnels for debugging and support tasks.
Audit tunnels that become part of production workflows instead of treating them as personal shortcuts.

Common mistakes

  • Forwarding a service to a public interface when it only needs to bind to localhost.
  • Leaving long-running tunnels undocumented after debugging is complete.
  • Confusing local and remote forwarding direction and opening the wrong path.

Troubleshooting signals

The tunnel connects but the app fails

Check the destination from the perspective of the SSH server. localhost on the remote side may not mean the same machine you expected.

Port already in use

Another local process or old tunnel may already be listening. Choose a different local port or stop the stale process.

Remote forwarding is refused

The SSH server may disable GatewayPorts or AllowTcpForwarding. Check sshd_config and security policy before enabling broader exposure.

Security notes

  • Treat a tunnel like temporary network exposure: know who can use it and when it should close.
  • Prefer binding forwarded ports to localhost unless a broader listener is required.
  • Use logs and team access controls for tunnels that become operational workflows.

Use SSH Bridge when this becomes a team workflow

SSH Bridge makes port forwarding a managed workflow with saved rules and visible controls, so private service access is easier to operate than hand-maintained terminal tunnels.

Download SSH Bridge