Sometimes you need to reach a machine that sits behind a network you don't control: no public IP and no inbound ports, sometimes behind several layers of NAT. Commercial tunneling tools like ngrok handle this well in many cases. When they didn't meet our technical requirements, I designed an internal alternative on plain OpenSSH.

Reverse the direction

The core idea is old: if you can't connect in, have the machine connect out. Each machine opens an outbound SSH connection to a bastion you control and asks it to listen on a local port. Anything that connects to that port on the bastion reaches the machine.

ssh -N \
  -o ServerAliveInterval=30 -o ServerAliveCountMax=3 \
  -o ExitOnForwardFailure=yes \
  -R 127.0.0.1:22001:localhost:22 \
  tunnel@bastion.example.com

Lock down every key

The tunnel account must not be a shell account. Each machine gets its own key, and the bastion's authorized_keys limits that key to one listening port bound to localhost, with no shell, PTY, or agent forwarding. A stolen key can open that one tunnel and nothing else, and revoking access means deleting one line.

restrict,port-forwarding,permitlisten="127.0.0.1:22001",command="/bin/false" ssh-ed25519 AAAA... device-001

Survive bad networks

Tunnels drop. Keepalives detect dead connections, ExitOnForwardFailure makes the client exit instead of running without a tunnel, and a service manager such as systemd restarts it. Giving each machine a fixed port from a registry makes it predictable to reach.

The bastion is where access is actually enforced. Keep it small and patched, log what happens on it, and let only the people who need it log in.

Build or buy

For many teams a commercial tool is the right answer, and I would start there. If it doesn't fit, OpenSSH already handles authentication, encryption, and forwarding. What you build is the policy around it, such as who gets a key, which port it may open, and how you take access away.