3 ms·
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 h
by saltcured 4mo ago
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.
- bheadmaster 4mo agoHow would you use ProxyJump with Reverse Forwarding?
- saltcured 4mo 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 4mo 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.