Live data from Hacker News

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

labs.iximiuz.com

41–50 of 83 posts

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

#41

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…

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

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

#42
post #4

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

>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.

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

#44
post #4

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

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.

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

#45
post #4

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

>ssh -J user1@bastion1,user2@bastion2 targetuser@targethost Are you using SSH key auth or password authenticating three times when you do this?

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.

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

#46

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 me…

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.

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

#47
post #9

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.

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

#48
post #27

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.
Post reply on HN