A Practical Guide to SSH Tunnels: Local and Remote Port Forwarding | Hacker News Reader

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

labs.iximiuz.com

381 pointssigna1177 comments

My favorite use of this is peer-to-peer transfer of Docker images. The Docker CLI only allows you to use registries authenticated with HTTPS but there's an exception where it allows HTTP transfers over localhost.

So, if you use SSH tunneling to forward a port from localhost to a remote, then Docker unwittingly pushes to a remote. This is super useful "off the grid" with robotics/embedded applications where you don't want to bother with a registry and a good Internet connection.

Example, docker pussh: https://github.com/psviderski/unregistry

iirc there's a setting to allow docker to trust and use http registries

i set it up a few years ago for my homelab

Which makes me think that I have never heard of signed images/artefacts

This is really useful as you don't have to add an entry under insecure-registries for local registries that don't have valid certificates.

You might as well handover the images to hackers.

A tad hyperbolic for a LAN registry

Not really since all it takes is one person with misconfigured device and your LAN is now accessible from who-knows-where unless the LAN is under very strict lockdown.

The SSL being turned off wouldn't matter in that case.

That's not quite true, you just need to add the `insecure-registries`[1] option with a list of either IP (or ip ranges) or hostnames that you want to allow without TLS.

```/etc/docker/daemon.json

  {
    "insecure-registries": ["10.100.0.0/24", "registry.yourmom.example.com:5000"]
  }

```

[1] https://docs.docker.com/reference/cli/dockerd/#insecure-regi...

Yes this is true. I should caveat that we distributed the tool among a team and we didn't want to ask them to all edit their daemon.json with an ever-expanding list of IP addresses.

Could the tool you distributed update the daemon.json for your users so they don't have to change daemon.json manually?

This is what kamal does when you use localhost as registry [0] [1].

Pretty cool thing, I ship plenty of services to my tiny $5/mo vps with it without having to pay for a docker registry.

[0] https://kamal-deploy.org/docs/configuration/docker-registry/...

[1] https://github.com/basecamp/kamal/blob/eee0083b38661c3707c6b...

I'll mention it here, because I learned about it here.

"~C" will drop you into the SSH command line, allowing you to, among other things, effect port forwarding

  -L8080:localhost:443

Learning that "~C" exists, and what you can do with it, has supercharged my use of SSH tunnels, which were already awesome on their own.

But for some reason this has been disabled by default in more recent ssh configurations... to ensure its available

  -o EnableEscapeCommandline=yes

or, in your ~/.ssh/config

  EnableEscapeCommandline yes

(edit: formatting)

Important to note that `~` SSH commands work only right after you press Enter - it doesn’t trigger everywhere you press `~`.

Also EnableEscapeCommandline fortunately only affects `~C` - the all-important `~.` to kill a hung SSH session still works with it disabled.

so many time i have inadvertently ended a session with a fat fingered ~.

Not ssh related but I regularly suspend my terminal with Ctrl-S by accident, usually when going for Ctrl-C/V.

That was a nightmare to triage back in the late 90s when I did it. Thankfully Ctrl-Q (I think it’s Q) “resumes”, so, easy fix if you know what you’ve done.

Correct.

- software flow control user

Eh, once I started using master sockets, I never went back. Problem with ~C is it's hard to keep track of what you have open.

I never pass up an opportunity to recommend the Cyber Plumber's Handbook: https://github.com/opsdisk/the_cyber_plumbers_handbook

Goes over similar content as TFA, in perhaps a little more depth. Indispensable sysadmin knowledge.

Appreciate the mention wbadart!

so good, I learn new things.

Not mentioning the ssh -w option in that book should be a crime.

Whoa that’s useful, learnt something new!

The article mentions bastions, but no jumphosting?

  ssh -J user1@bastion1,user2@bastion2 targetuser@targethost

Edit: Jumphosting was introduced in OpenSSH 7.3 2016-08-01.

https://www.openssh.org/releasenotes.html

It is surprising how many times I see this content (this version might be marked “Published: Jun 19, 2026” but I've definitely seen those exact diagrams before, starting at least a few years ago, and the same content around them in many tutorials before that) without it being updated to mention jump-hosts.

Support was added to OpenSSH about a decade ago? Even on a low moving Linux distro like Debian/LTS everyone should have support by now.

>ssh -J user1@bastion1,user2@bastion2 targetuser@targethost

Are you using SSH key auth or password authenticating three times when you do this?

If you don't have an agent running with an accessible key, then you will get three password prompts, with suggestions for any default keys.

The final target is a pre-elliptic curve OpenSSH server, so legacy is enabled. I could probably have removed that for clarity.

  C:\Users\me\>ssh -J me@bhost1,me@bhost2 -o KexAlgorithms=diffie-hellman-group14-sha1 -o HostKeyAlgorithms=ssh-rsa -o MACs=hmac-sha1 oracle@target
  Enter passphrase for key 'C:\Users\me/.ssh/id_ed25519':
  me@host1's password:
  Enter passphrase for key 'C:\Users\me/.ssh/id_ed25519':
  me@host2's password:
  oracle@target's password:
  Last login: Wed Jun 24 13:29:55 2026 from bhost2

That client is Microsoft's port of OpenSSH.

I always use keys in my SSH agent.

Because the jump mechanism works via use of TCP forwarding, each host authn step is talking "directly" to your client. Importantly, this means it still works without requiring "agent forwarding" for the connection you are making.

For me, this is always used via ProxyJump rules in my ~/.ssh/config

It is also nice that it works recursively, so I can logically structure my rules so that the one for my regular targets say to use bastion1, then the rule for bastion1 says to go via bastion 2, etc.

I find this easier to reason about and maintain rather than juggling a bunch of these multi-step rules.

And with match/exec rules you can always connect to MyHost and make it conditional whether to use a jumphost or not, so it's like an on demand vpn.. only with ssh.

    Match host="MyHost" exec "! grep Home ~/.wifi-loc-control/.current"
    ProxyJump home-jumphost.mydomain.tld

What I've found beautiful about -J is the host you jump through requires no privileges on the final host. Only my laptop has the SSH key to access my home server, not my cheap VPS.

And this allows me to have zero open ports on my home internet. I do a reverse tunnel to my VPS from my home server (in a FreeBSD jail), and that port is what my laptop client jumps through.

Need to mention sshuttle [0] here, as it magically solves a bunch of these problems without constant reconfiguration

[0] https://github.com/sshuttle/sshuttle

sshuttle is amazing. I've used it extensively on stupidly configured networks, super useful tool.

Yup, use it regularly in order to jump through networks where a VPN/Wireguard setup is not possible. It can also forward DNS requests and handle local NS operations reasonably well, such that it can be used as a low-key split-VPN client (i.e. only forwards traffic for a specific domain or IP range without redirecting any other traffic). Note that for integration with `systemd-resolved`, one needs to jump through a few hoops, but I feel its works very nicely: https://github.com/sshuttle/sshuttle/issues/688#issuecomment....

Learning how SSH port forwarding is great as a pseudo-vpn for everything from GUI-client database access to (in physical infra) access to web-admin tools for appliances.

The socks proxy support can also deal with bad web filtering and privacy issues on public wifi networks (though nowadays if you're ssh'ing to a cloud IP, you'll get lots of "bot" restrictions).

Yeah, I get use out of the SOCKS proxy mode in combination with a "split VPN" at work.

I need VPN to get into some internal resources via SSH, but there are lots of external/public/AWS resources I also need to access, and the full VPN adds too much overhead and fragility for those.

Using the available split VPN, I can point a browser instance at a localhost SOCKS proxy port to relay over SSH + VPN for other web resources I need to access internally.

Unfortunately, Firefox proxy config rules are sort of backwards for my needs. I want to say "only use proxy for these 3 domains" whereas it wants to use the proxy by default and only allow me to bypass specific domains.

In the past, I've used plugins to do just what you ask. FoxyProxy Standard did the trick (it looks like there's now at least another more standard "VPN" version, too). It looks like Firefox does have support for Native PAC files that'll also do the trick: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Pro...

Firefox can be used with socks proxies nicely.

- Use Multi-Account Containers plugin, where you define which domain should be opened in which container.

- Use Container Proxy to configure which socks proxy to use for different containers.

Pair that with ssh tunnel that you use as socks proxy and you have nive tunneling solution for browser.

Maybe, but what I want is just a toggle or something in the very basic manual proxy config to invert the current configuration model.

Here's my ad-hoc proxy. Use it for only these domains (while everything else goes direct).

After I complete my special tunneling task, I'm going to flip it back to "no proxy" and resume normal life.

I've been a very happy user of firefox container tabs, but this is the first I'd heard of container proxies. Any resources on them you can share?

Or use plugins like foxyproxy that implement transparent rule-based routing without containers.

> The socks proxy support ...

I just love SOCKS proxy in SSH tunnels: at some point I had a dedicated server (on a fixed IP) with countless machines (usually headless Pis dropped at a family member's place and/or SME office) automatically setting up, 24/7, reverse tunnels to that dedicated server.

Then I could, from anywhere, both access their LANs (to fix stuff) and have a browser, running locally, pretending to be in this or that country.

Basically because I had all those reverse tunnels always there, I could always decide how to use them (just SSH in or SOCKS in etc.).

Hak5 video that helped me understand many years ago about the practical usage of SSH forwarding

Hak5 - SSH Forwarding: Local vs Remote with examples, Hak5 1113 part1 https://www.youtube.com/watch?v=g_Row8zEJZc

BTW I use this and a systemd unit file and SSH tunnel my Jellyfin to a public VPS to its local host.

I then use nginx to proxy it.

Because its a unit file, sshd reconnects if my ISP's IP changes. Does so within 30s. Also hides my ISP IP in case I have to turn it off.

And no data is effectively on the VPS. Its just a mostly empty machine.

If you have many different remote devices behind NATs or firewalls, a cool trick to access them all via EC2 server (or such) is to setup Remote Forwarding via UNIX socket on the server side, to devices' port 22. Preferably, UNIX socket filenames should start with a common prefix, so an SSH config can be written that will use ssh+socat in a ProxyCommand to establish the connection.

It's amazing how lightweight this method actually is. I have managed to connect hundreds of devices using a single EC2 nano instance.

Do you have more info on this method? How is the remote forwarding actually done?

There's an old blogpost I wrote at the time I came up with this method [0]. I think it contains most of the technical details.

Let me know if anything is confusing, I'll answer it here.

[0] https://paskozdilar.github.io/blog/entries/zero_code_ssh_jum...

Maybe I'm missing something, but wouldn't the ssh -J option be much easier?

How do you use -J to connect to a device that isn't publicly reachable?

I think the more modern ProxyJump rule is superior for this. Just let it manage the actual TCP forwarding for you automatically. It's just the normal "bastion host" concept.

Particularly, you can use name patterns to apply the same rule broadly, assuming you have some systematic naming scheme for your eventual target devices.

How would you use ProxyJump with Reverse Forwarding?

Oh, I think I misunderstood your description. I just jumped to the conclusion of a bastion host being used via the old proxy command method (what we did before the "jump" feature got added).

But, you're saying all these remote devices individually connect "back" to the central host to keep a tunnel open?

Honestly, I've never had this problem at large scale. When I did have it, I used one of these methods rather than SSH TCP tunneling tricks:

1. I'm in control of the firewall/NAT router itself, deployed OpenWRT, and setup the port-forwarding rules there (i.e. iptables address rewriting).

2. I really need to punch through uncooperative NAT, so I setup OpenVPN with that remote device initiating the persistent tunnel.

In some corporate networks, everything is locked tight, and if you want any access (outbound or inbound), you have to send a request with business justification.

What we had was many devices behind such corporate networks. Instead of requesting exposed ports for each device, or setting up OpenVPN (never done it so I'm not sure how much the red tape would it be), I requested only outbound access to our bastion server's SSH. Since SSH is pretty standard, admins usually allow it fairly quickly.

There were also a few cases where non-HTTPS connections were also banned, so we set up an HTTPS proxy that tunneled the SSH reverse forwarding... But that's probably not needed in most cases.

It’s amazing what you can learn by reading the manual.

It is, because manuals are often not the best way to learn things. Most software manuals are reference manuals. SSH man page isn't too bad. I learned most of my SSH knowledge from it, but I'm not sure it's the best way to do it.

For me, the best way to learn a tool is for a quick example or two showing its utility, then practicing with those, reading the man as needed on specific flags. Google or bot ”how do x" ? Repeat : done

Some pages have a nice up-front synopsis of flags, others put them in a wall of text. Browsing the former can supplant Google, /\b-x while paging is helpful for the latter.

It's amazing how badly written most manuals are.

That’s quitter talk.

Reminiscent of Steve Friedl's excellent work: http://www.unixwiz.net/techtips/ssh-agent-forwarding.html

When I see one of these with obvious AI tells at the top (sentences lacking a subject or verb), I ask myself:

Can’t I just open up a harness and prompt “Teach me how to do X?”

I personally do this, ask claude code to teach me about concepts I don't know about when it codes something, and only then I accept what it suggests to me

I do this all the time, I have a skill/gem with instructions on how I want to receive info, how to format and so on. Really helps to go fast to get the point.

Could you share it? I'd be interested to get idea to make my own

It goes like this: --- As an expert tutorial creator for experienced engineers, you take the input the user request and make interactive tutorial. Default style is technology, tech is mac and linux. Default style is 20mins, but you ask for the timeline. Also do not forget to provide the cost of technologies used. ---

The best part of this is you can daisy chain tunnels and have a network connection between any machines you can ssh into.

If you have a private server with a public IP, you don't need localtunnel etc.. you can just use ssh tunnels to expose your home network services over public IP.

Or you could just install something like Tailscale and never have to think about it again.

or tell an llm to do it for you

There's a asymmetry here that "-R" works both for reverse static and dynamic (using SOCKS protocol) forwarding, but "-D" is required for dynamic forwarding which "-L" cannot do.

Why is that?

It's historical. Some older flags could be easily extended for dynamic port support and others could not.

As a sysadmin, one of your biggest ROI is learning the ins and outs of SSH.

Thanks! I will keep this for reference. I use ssh alot but thie reminds me that I can learn new ways of tunneling :-)

I think that the start of the article is at least a bit exaggerated:

    SSH is yet another example of an ancient technology that is still in wide use today.

Ancient technology? If it was telnet or FTP... But SSH is much younger than, let's say, IPv4, which is _maybe_ ancient technology still in wide use today.

Weird.. I have almost this exact same "cheat sheet" printed out and stuck up on my whiteboard.. except it's slightly different. Only 4 panels instead of 6 and the panels don't have titles.

I know this is a solid "cool story bro" moment, but whatever hah

Another option that I never see mentioned anywhere is -w which allows you to create either layer2 or layer3 tunnels via a tun(4) interface.

Always annoys me -p(port) for ssh clashes with -p(reserve permissions) for sftp and scp. Unavoidable given history.

Also annoys me we "invented" ssh:// url format after the tools were baked so it's a somewhat odd bonding into the model.

Very refreshing to see a utilitarian series such as this. Disappointing that the latest ai drama gets 20x more discussion and visibility on this site

Should add how to bypass MFA using phishing and SSH Multiplexing to the article.

Reply on news.ycombinator.com