SSH tunnels: local, remote and dynamic port forwarding

What it is

The ssh(1) manual describes three forwarding modes. -L [bind_address:]port:host:hostport listens on a local port and forwards each connection over the secure channel to host:hostport as reached from the remote machine (local forwarding). -R [bind_address:]port:host:hostport listens on the remote host and forwards connections back to a destination reachable from the client (remote forwarding); given only a port, the client acts as a SOCKS proxy for the remote side. -D [bind_address:]port opens a local SOCKS4/5 proxy whose destination is decided per connection (dynamic forwarding). -J destination connects through a jump host first, a shortcut for ProxyJump. -N runs no remote command, which the manual notes is useful for just forwarding ports. Unix sockets can be forwarded as well. The listening side is bound according to GatewayPorts; a bind_address of localhost keeps the port local, while * opens it on all interfaces.

Why it matters

Tunnels reach databases, admin interfaces and internal APIs that are deliberately not exposed, without opening firewall ports, using the same keys and logs as interactive SSH. The same mechanism makes a carelessly bound tunnel a way to publish an internal service to the network.

How to apply

• Reach a database on a private network: ssh -N -L 5433:db.internal:5432 bastion, then connect to localhost:5433.
• Show a local development server to a remote machine: ssh -N -R 8080:localhost:3000 host. On the server, GatewayPorts in sshd_config decides whether other hosts may connect to that port; the default binds remote forwards to loopback.
• Browse through the remote network: ssh -N -D 1080 host and point the client at the SOCKS proxy.
• Hop through a bastion: ssh -J bastion target, or ProxyJump in ~/.ssh/config; keep forwards there as LocalForward and RemoteForward so they are reproducible.
• Set ExitOnForwardFailure yes so ssh terminates when a requested forward cannot be bound instead of continuing without it; add ServerAliveInterval so a dead connection is noticed.
• On servers, restrict forwarding with AllowTcpForwarding (no, local or remote) for accounts that do not need it.

Pitfalls

A forward that "works" may belong to an older ssh process still holding the port; check listeners with ss -ltnp. Only the superuser can forward privileged ports. -R does not open the remote firewall. ExitOnForwardFailure covers only the listener setup, not failures to reach the final destination. Tunnels bypass network policy by design, so document every standing one.