The unreachable machine is a design flaw, not a fact of life
Every homelab and every small IT shop eventually collects machines it can’t comfortably reach. The Raspberry Pi at a relative’s place, stuck behind carrier-grade NAT. The little server at a client’s office, where the router is owned by someone else and the firewall policy is “no”. The edge box in a workshop that you see twice a year. The traditional answers are all bad in familiar ways: forward port 22 and pray, keep a jump host alive, or bolt a VPN onto hardware you don’t fully control.
There’s a better shape for this problem, and a recent overview of ShellHub over at OpenSourceProjects.dev prompted me to write up why I think it matters. ShellHub flips the direction of the connection: instead of you fighting your way into remote machines, each machine calls out to a gateway you run. It’s an Apache-2.0 project from O.S. Systems, and it deserves a slot in more homelabs than it gets.
What ShellHub actually is
ShellHub is a centralized, self-hostable SSH gateway. You run the gateway — on your own hardware or a small VPS — and install a lightweight agent on every Linux device you want to manage. The agent makes an outbound connection to the gateway and registers the device. From then on, you reach that device through the gateway using the tools you already use: plain OpenSSH, PuTTY, scp, sftp. No proprietary client, no agent-side port openings, nothing listening on the remote network.
There’s also a web interface and a mobile app, so you can get a shell from a browser when you don’t have your keys handy — useful when the “incident” is happening on your phone in a supermarket queue. Port forwarding works too, including SOCKS proxying, which quietly covers a lot of “I just need to reach one internal service” scenarios. And it integrates with Docker, so you can drop into containers on a host without first SSH-ing in and running docker exec yourself.
The trick is the direction of the connection
Most remote-access pain is really about inbound connections. CGNAT breaks them, client firewalls block them, and every listening port is an attack surface you now own. ShellHub’s model removes the entire category: the only inbound-exposed thing is your gateway, which is one box you can harden, monitor, and put behind TLS and a reverse proxy you already trust.
That asymmetry is the whole product, and it’s why the setup story is so short. Install agent, accept the device in the web UI, done. No router configs, no dynamic DNS, no “can you open a port for me” emails to a client’s IT person who doesn’t exist.
Where it earns its keep: the audit layer
For me, the gateway plumbing alone wouldn’t justify another service to run. What makes ShellHub interesting is everything stacked on top of that plumbing:
- Per-user public keys. Multiple people can log in as the same system user without sharing a password, and you revoke one person’s access without touching anyone else’s. That is how access control should work, and it’s rare to get it for free.
- SSH firewall rules. Fine-grained control over which connections may reach which devices, enforced at the gateway.
- Audit logging. Every connection through the gateway creates a stored session record.
- Session recording. Interactive sessions are recorded and replayable in a built-in player in the web UI.
That last one is the feature small businesses keep wishing they had after something goes wrong. When a technician works on a client box at 11pm, “here’s the recording” beats an hour of reconstruction from shell history. It’s also a genuine compliance lever, not just a paranoia feature.
When I’d run it — and when I wouldn’t
Be honest about the shape of your problem before adopting this. ShellHub shines when the fleet is heterogeneous and partly not yours: client machines, family machines, embedded or IoT devices in the field, or contractors who need shell access but should never be handed a spot on your WireGuard mesh. Per-person keys, revocation, and recordings are exactly the controls that situation lacks.
If it’s three boxes that are all yours in one building, a mesh VPN is simpler and gives you the whole network, not just shells. I run Tailscale-shaped things for my own day-to-day access and don’t feel bad about it. ShellHub is the tool for the moment access needs to be managed, not just established.
Running it yourself
The fastest honest evaluation is the hosted ShellHub Cloud — connect one device, see whether the workflow fits your brain. If it does, self-hosting is the natural endpoint for this audience. The project ships a compose-based deployment; follow the self-hosting guide rather than hand-rolling your own compose file, because the stack has several services and its own wrapper scripts. To poke at the code locally, the development bootstrap is pleasantly short:
git clone https://github.com/shellhub-io/shellhub.git
cd shellhub
make keygen
make start
./bin/cli user create <username> <password> <email>Two operational notes from the “things I do to my own infrastructure” file. First, the gateway is now critical infrastructure: it belongs in the must-be-up tier next to your reverse proxy, with its data backed up and updates applied on a schedule. Second, keep one out-of-band path to your boxes — a VPN that isn’t related to ShellHub, or console access. If your only door is the gateway and the gateway is down, you’ve rebuilt the unreachable-machine problem you started with, one level up.
Verdict
ShellHub doesn’t try to reinvent SSH, and that restraint is why it works. Your existing clients keep working, your muscle memory keeps working, and what you gain is the part SSH never had: a front desk. Devices call home, people get named keys, sessions get recorded, and port 22 stays closed everywhere but the one place you watch. For anyone supporting machines on networks they don’t control — which is most of us by the second client — that’s a clean upgrade to how you operate.