HN Debrief

A Practical Guide to SSH Tunnels: Local and Remote Port Forwarding

  • Infrastructure
  • Security
  • Developer Tools
  • Networking

The article is a practical primer on SSH tunnels. It explains local port forwarding with `-L`, remote port forwarding with `-R`, and how to use those to reach internal web apps, databases, or other services through a machine you can already SSH into. That is useful baseline material for anyone who knows SSH as a login tool but has never internalized that it can also move arbitrary TCP traffic around.

If your team still treats SSH as just remote shell access, you are leaving a lot of operational leverage on the table. Standardize a few patterns in your SSH config now, especially ProxyJump and dynamic forwarding, and decide where SSH tunnels stop being a clever workaround and a mesh VPN becomes the better default.

Discussion mood

Positive on SSH tunneling as a durable, high-leverage skill, but mildly frustrated that the tutorial covered the old basics and skipped the modern conveniences people actually use. The strongest reactions were about omissions like ProxyJump, SOCKS mode, and other operational tricks that make SSH tunnels less brittle in real environments.

Key insights

  1. 01

    Add tunnels without reconnecting

    SSH can change a live session in place with the `~C` escape command, which drops you into an interactive mini prompt for adding port forwards. That turns tunneling from a command you plan up front into something you can adjust mid-debugging session, as long as you know escapes only work right after pressing Enter and newer configs may require `EnableEscapeCommandline yes`.

    Teach this to anyone doing incident response or production support over SSH. It cuts the cost of experimentation because you stop tearing down and rebuilding sessions just to expose one more port.

      Attribution:
    • buredoranna #1
    • telotortium #1
  2. 02

    ProxyJump replaces a lot of tunnel glue

    `ProxyJump` is the cleaner answer for bastion traversal than many older forwarding recipes. It keeps authentication between your client and each hop, avoids needing agent forwarding for the final connection, composes recursively in `~/.ssh/config`, and can be made conditional with `Match exec` rules so the same host alias works differently on home, office, or travel networks.

    If your SSH docs still teach multi-hop access with ad hoc forwards or custom `ProxyCommand` snippets, rewrite them. A small shared SSH config with `ProxyJump` rules is easier to audit, easier to explain, and less likely to rot.

      Attribution:
    • chasil #1
    • idatum #1
    • saltcured #1 #2
    • 05 #1
  3. 03

    SOCKS mode acts like app-level VPN

    Dynamic forwarding is what many people actually use, because a local SOCKS proxy gives one browser or client selective access to internal or geo-specific networks without pushing all traffic through a full VPN. That is especially handy in split-VPN setups and for remote support fleets where always-on reverse tunnels let you choose later whether to SSH directly or route browser traffic through a specific site.

    For teams that only need access to a few internal dashboards or appliances, start with SSH SOCKS proxies before rolling out heavier network changes. Pair it with browser profile or proxy tooling so the route stays explicit and limited to the apps that need it.

      Attribution:
    • hylaride #1
    • saltcured #1
    • TacticalCoder #1
  4. 04

    Localhost tunneling sidesteps Docker registry friction

    A practical hack for offline or unreliable environments is to tunnel a remote image registry back onto `localhost`, because Docker treats localhost HTTP more leniently than arbitrary insecure registries. The correction in the replies matters though. Docker can be configured to trust insecure registries directly, so the tunnel is most useful when you want zero daemon config churn across a team or a moving set of device IPs.

    If you distribute containers into field devices or robotics deployments, compare the operational burden of managing `insecure-registries` against a localhost tunnel pattern. The right choice depends less on security theory and more on how many machines and changing endpoints you have to support.

      Attribution:
    • tangotaylor #1 #2
    • mmh0000 #1
    • QGQBGdeZREunxLe #1
  5. 05

    Tiny CLI quirks still bite experts

    Even seasoned users still run into odd SSH ergonomics, from `ssh -p` meaning port while `scp` and `sftp -p` mean preserve permissions, to confusing or inconsistent shortcut patterns across related tools. That sounds minor until you remember most teams learn SSH from copied snippets and cheat sheets, where one bad assumption can persist for years.

    Build internal examples around `~/.ssh/config` host aliases instead of long one-liners. That reduces memorization load and avoids subtle flag mistakes that only show up during stressful production work.

      Attribution:
    • ggm #1
    • ktm5j #1
    • Bender #1

Against the grain

  1. 01

    Mesh VPN can make tunnels unnecessary

    Tailscale was offered as the blunt alternative to all this manual forwarding. The point is not that SSH tunnels are obsolete. It is that once the job is stable private connectivity rather than a one-off path to one service, a mesh VPN removes a lot of cognitive overhead and tribal knowledge.

    Choose SSH tunnels for targeted access and debugging. Choose a mesh VPN when you want routine connectivity that other engineers can use without becoming SSH specialists.

      Attribution:
    • segphault #1
  2. 02

    sshuttle covers the messy middle

    sshuttle was recommended as a pragmatic step between manual tunnels and a full VPN rollout. It can route traffic over SSH with much less per-service setup, which is why people reach for it on badly designed networks where classic forwarding gets tedious fast.

    Keep sshuttle in your toolbox for environments you do not control, especially customer or inherited networks. It is often the fastest path to useful connectivity when a proper network redesign is not on the table.

      Attribution:
    • smw #1
    • mystifyingpoi #1
  3. 03

    Generic AI tutoring may beat static tutorials

    Several comments treated the tutorial itself as less valuable now that people can ask an LLM to generate a tailored walkthrough or explain specific SSH concepts on demand. The interesting part is not hype. It is that reference-style material competes poorly against interactive teaching when the reader already knows enough to ask good follow-up questions.

    If you publish technical onboarding content, assume static cheat sheets are now the floor. Add concrete scenarios, failure modes, and decision guidance that a generic prompt is less likely to supply reliably.

      Attribution:
    • trollbridge #1
    • lfx #1 #2
    • GL26 #1

In plain english

Docker ↩
A platform for building, packaging, and running software in containers.
NAT ↩
Network Address Translation, a technique that lets multiple devices share one network connection or public address.
ProxyCommand ↩
An older SSH configuration option that runs a command to create the network connection SSH will use to reach a host.
ProxyJump ↩
An OpenSSH feature, usually used with `-J`, that connects to a target host by automatically hopping through one or more intermediate SSH servers.
registry ↩
A server that stores and distributes container images for tools like Docker.
SOCKS ↩
A proxy protocol that lets applications send network traffic through an intermediary server without needing a separate VPN.
SSH ↩
Secure Shell, a protocol and tool for securely logging into remote machines and forwarding network traffic.
systemd ↩
A Linux system and service manager often used to start, stop, and automatically restart background processes.
VPN ↩
Virtual Private Network, a way to route traffic through a private encrypted network as if your device were directly connected to it.

Reference links

SSH and tunneling references

Tools and utilities

  • unregistry
    Example tool for peer-to-peer Docker image transfer using SSH tunneling instead of a conventional registry.
  • Docker insecure-registries documentation
    Used to correct the claim that Docker only allows HTTP registries on localhost.
  • sshuttle
    Recommended as a simpler way to get broad connectivity over SSH without setting up many individual forwards.

Browser proxy configuration