The most common question about Shellius is whether users need a VPN to reach hosts on a private network. The answer depends on how they connect, because not every route leaves from the same machine.
Two classes of route
| Route | Who opens the TCP connection | Which machine must reach the host |
|---|---|---|
| Browser terminal (SSH) | The Shellius backend, over ssh2 | The backend |
| Browser RDP | guacd, running beside the backend | The backend |
shellius terminal client | Your machine, by running ssh | Your machine |
Downloaded key with your own ssh | Your machine | Your machine |
| Quick Connect (browser) | The Shellius backend | The backend |
- Connection Shellius opens for you
- Connection your own machine opens
- API call
Browser routes are server-side. When you open a web terminal, your browser holds a WebSocket to Shellius; Shellius makes the SSH connection to the target. The target never sees your laptop's address, and your laptop never needs a route to the target.
Client routes are not. The terminal client runs ssh on your own machine. Shellius hands it a certificate and gets out of the way.
What this means in practice
A host on 10.0.0.0/8 with Shellius inside that network. Browser terminal and RDP work from anywhere on the internet, with no VPN. The terminal client only works when your laptop is on the network — typically over a VPN.
A host on a private network with Shellius outside it. Nothing works until something bridges the two. Shellius has no tunnelling of its own.
A host with a public address. Everything works either way.
This is why a common deployment is Shellius inside the private network with only its web interface exposed: browser access works for everyone, without putting every user on a VPN, while the sensitive traffic stays internal.
The portal flags private addresses on servers, access requests and connect dialogs with exactly this warning, so people are not surprised at connect time.
What it means for trust
The convenience has a cost worth stating plainly.
On a browser route, Shellius is in the network path. It terminates your SSH session and speaks to the target itself. That is what makes session recording possible at all, and it means a compromised Shellius host can observe browser sessions in plaintext. On a client route Shellius is not in the path and cannot see the session — it only issued the credential.
If that distinction matters to you, prefer the terminal client for your most sensitive hosts, and read the threat model.
Firewall rules you actually need
Whichever route you use, the target host needs outbound HTTPS to the Shellius API, because check-principals calls it on every incoming connection. That is separate from how the SSH connection itself arrives.
| Direction | Purpose |
|---|---|
| Target → Shellius API (HTTPS) | check-principals validation and the heartbeat. Required always. |
| Shellius → target (port 22 / 3389) | Browser terminal and RDP only. |
| Your machine → target (port 22) | Terminal client and downloaded keys only. |
| Your browser → Shellius (HTTPS/WSS) | The portal and browser terminals. |
No inbound port is ever opened on the target by Shellius itself.
Troubleshooting
Browser terminal fails but the CLI works. The backend cannot reach the target. Check from inside the container rather than from your laptop:
docker compose -f docker-compose.prod.yml exec backend sh -lc 'nc -vz 10.0.0.5 22'The CLI fails but the browser terminal works. Your machine is not on the network. Connect to your VPN.
Both fail, and the host shows as unreachable. The target cannot reach the API — check its outbound HTTPS and the heartbeat timer. See Troubleshooting.