[saltcured]

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.

[bheadmaster]

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.