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

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

iximiuz.com

319 pointssigna1128 comments

At a former company, we needed to connect to customer's databases from our service. Many were understandably cagey about opening a public hole in their firewall to their DB, even if it's just for our single egress IP.

Our solution was to run a public host (the Reverse Bastion) that would, upon user request, generate a shell-less linux account for the user and install their public key. The user was then given an SSH command to run from inside their corp network that would connect to Reverse Bastion and establish a reverse tunnel pointing at their database. That way we could "connect" to that user's dedicated port on the Reverse Bastion and our traffic would traverse the tunnel and pop out inside their network, bound for their database. Since it's all TCP tunneling, JDBC drivers had no idea they were hopscotching around networks and did DB queries like usual. As long as you have the user accounts totally locked down and people's port assignments locked to their users via iptables, it was a walled (tunneled?) garden.

From experience I can tell you that such a setup is very brittle and will fail the moment the one employee of that customer who knows about this is on vacation or working at a different place.

The only thing that works reliably is a proper VPN (configured for machine to machine access, not based on username/password which has the same brittleness issue) which these days is available at every customer's site.

I agree with the reliability issue, but I can't stop myself from mentioning that I had an autossh connection set up on systemd that worked for an impossible five years until our support contract expired.

This.

Port forwarding goes both ways.

I may, or may not, have used ssh forwarding and reversing forwarding to create a shadow IT tunnel(s) between my home and work when VPN was acting up.

Also, SOCKS proxy is very useful if you can puncture a hole home and your work requires a proxy to access the World Wide Web from the office location.

You were one of the reasons I wanted to block outbound non-web traffic from clients at the perimeter when I was a CISO. Unfortunate for me, but I guess fortunate for the developers, who wanted to SSH home, I got vetoed.

Networks with outbound SSH access blocked are depressing. It‘s not that hard (but still annoying) to tunnel through them via HTTPS or similar.

I do understand the pain when it's a public one, but in corporate land it really does make big difference for security.

If you have the funds the Deep Packet Inspection is a big way to defeat attempts to tunnel through HTTPS, DNS, or the like.

Only if you SSL inspect which is a god awful maintenance/support burden even if you already have full control of every system which accesses the web from your network (pretty much excluding any usable guest access otherwise that becomes the next hole). There are definitely places that level of security make sense to maintain but typically as a requirement not something someone wants to do.

Even then you haven’t really solved that particular issue as it’s a people problem not a tech problem. It’s like trying to stop an employee from robbing the bank by getting a thicker vault door in that it’s just not the right type of incentive/disincentive to make an impact.

There are also countless ways to evade this: iodide (tunnel over dns), encapsulating encryped traffic in non-encrypted http, etc.

DPI just makes it harder, so does terminating ssl earlier, or blocking outbound ports.

> in corporate land it really does make big difference for security.

When measuring security by "number of boxes checked", yes. Unfortunately, these boxes are often overly generic, years too old, or both.

> If you have the funds the Deep Packet Inspection is a big way to defeat attempts to tunnel through HTTPS, DNS, or the like.

What's there to inspect (unless you are decrypting all TLS in a middlebox with a root CA trusted by all clients)? How would you distinguish a "normal" WebSocket connection (as used by many sites these days) from a tunneled SSH connection, for example?

If you generally want to allow your users to reach the broader public internet (or even just web), this approach seems completely futile.

A cool feature in recent ssh is SOCKS5 remote forwarding.

Doing something like this from host B:

   ssh -N -R 1080 user@A

Will allow a browser running on A access network through a SOCKS5 proxy on B while setting the proxy as localhost:1080.

This is a handy resource, SSH tunnels are something that I always find easier to grasp when displayed visually.

I use a reverse SSH tunnel to access my home network when traveling.

Ex:

- [Machine-A (on my LAN, behind NAT, with a dynamic IP address)] maintains a long lived SSH connection to [Machine-B (a VPS with a public IP)] with a reverse tunnel configuration.

- I can then SSH into Machine-B and follow the tunnel back into Machine-A, and from there access the rest of my home network.

It works pretty well. I can access files on my NAS and check on my Raspberry Pi cameras without needing to put either on "the cloud". Although I have to admit I always have to pull up a resource like the one in OP whenever I want to setup something like this, I've never learned it by heart and always need a refresher.

When it comes to accessing my home network from outside, Wireguard replaced these kinds of hacks for me.

I just use zerotier, no need to own / set up a VPS. But if I wanted to have all components under my control, then I'd do the same thing as you.

FWIW, none of this made any sense to me until I mentally ditched the concept of "tunnels." The metaphor was too physical for me?

Personally, the metaphor that made it work for me was "postcards going to a motel." As in AHA, when I'm doing SSH Tunnelling, Room 22 is the only one open and receiving mail, all the other rooms are locked. Now, there might be a website behind the door on locked room 443, and I can send my postcards to room 22 with the instructions to send them on over to 443 once they get there, and over at the motel they'll also know to do the reverse.

Awesome resource!

Bookmarked / saved to PKM.

Aside from the pretty Excalidraw diagrams, clear prose, and IRL use cases, I'm grateful for eg this tiny gem:

"The mnemonics are "ssh -L local:remote" and "ssh -R remote:local" and it's always the left-hand side that opens a new port."

The confusing part is treating "port forwarding" as a single word.

It should be read as local port (forwarding) and remote port (forwarding).

With local, the listening port is local. With remote, it is remote.

You wouldn't believe how difficult it is to teach the concept of tunneling to some students. It made my brain hurt at times. I guess once you get it you just get it.

Also this is one of the coolest uses of SSH tunnels that I recently found: https://github.com/regymm/termux-reverse-ssh

It's pretty scary how some vendors poke holes into your home network using tunnels.

Actually the concept is easy as those diagrams demostrate. It's the syntax in ssh that's hard to grasp. They should keep the current one forever but deprecate it. Then add a parallel syntax easier to understand. Example

  ssh connect
    remote myserver:80 
    to local 172.27.17.2:8080
    one-way

The syntax should totally do away with the concept of tunneling, connecting ports is easier to grasp IMHO. BTW I'm not sure that the "one-way" argument is really needed.

Your machine can also act as a bastion to a remote resource for the rest of your network through local port forwarding, e.g. -L 0.0.0.0:8080:localhost:8080

Then any local machine can e.g. curl yourip:8080 and the request will go through your machine, over the SSH tunnel, to the remote machine

Sorry but how is that different to what the blog post says?

Anyone know of an open source solution that is the same/similar to thing that some vendors build into their product to create “support tunnel”? Usually, it’s a toggle in the settings that establishes a connection that a support person can use to connect back to the appliance or virtual appliance. I imagine it’s a reverse tunnel or similar to one. However, the solution would need to pop up on a dashboard or screen so that support person knows it’s active and how to connect to it.

Nice visual. My version uses the TUN devices. http://dusted.dk/pages/aWayOut/

I am not seeing dynamic and the newish reverse dynamic tunnels here which are just setting up a socks proxy to access any network the client or server can access.

I wonder if it makes sense from the security perspective to access applications using ssh port forwarding, rather than opening ports for the applications?

Tangent: what tool was used to generate those awesome diagrams?

Don't know but I've used Excalidraw for that hand-sketched feel.

I find this useful!

Reply on news.ycombinator.com