7 ms·
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 U
by bheadmaster 3mo ago
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.
- ranger_danger 3mo agoDo you have more info on this method? How is the remote forwarding actually done?
- mldbk 3mo ago[dead]
- bheadmaster 3mo agoThere'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_jumphost.html https://paskozdilar.github.io/blog/entries/zero_code_ssh_jum...
- ranger_danger 3mo agoMaybe I'm missing something, but wouldn't the ssh -J option be much easier?
- bheadmaster 3mo agoHow do you use -J to connect to a device that isn't publicly reachable?
- saltcured 3mo agoI 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.
- bheadmaster 3mo agoHow would you use ProxyJump with Reverse Forwarding?
- saltcured 3mo agoOh, 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.
- bheadmaster 3mo agoIn 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.