SSH Tunnels Demystified: Local vs. Remote Port Forwarding

SSH port forwarding remains one of the most useful tricks in a developer’s kit, yet the exact syntax is notoriously easy to forget. This tutorial walks through both directions of tunneling using a four-host lab spanning a home network, a public network, and a private VPC. The two workhorses are local forwarding (-L) and remote forwarding (-R), and the guide leans on diagrams and a cheat sheet to make the distinction stick.

Local forwarding (ssh -L local_port:remote_addr:remote_port host) pulls a remote service onto a port on your own machine. The key insight is that the forwarding target need not be the SSH server itself: by pointing the destination at an internal address, you can use a public-facing bastion or jump host to reach services buried inside a VPC—a private database, an OpenSearch cluster, or a loopback-bound web server—that your laptop has no route to otherwise. Remote forwarding (ssh -R) does the inverse, exposing a service running on your local machine through a public gateway, which is handy for quick demos or surfacing a homelab to the internet. The catch is that by default the exposed port is only reachable from the gateway’s own localhost; making it publicly accessible requires setting GatewayPorts yes in the SSH daemon config.

Throughout, the author recommends -f -N to run tunnels quietly in the background, and frames SSH fluency as a durable skill worth more over time than chasing tools that may be deprecated next quarter. The piece doubles as a mnemonic aid for anyone who keeps second-guessing whether they need -L or -R and which port goes where.