First published on the RescueShell blog.
The first question a customer's IT department asks is "is this a VPN?". The honest answer is no,
and the reasons are the whole design.
A VPN joins networks. We join one shell.
A VPN puts two networks on one fabric. Once it is up, anything on one side can try to reach
anything on the other. Firewall rules then try to take that back.
Our agent does the opposite. It opens one outbound connection to our relay, over TLS on port 443,
and holds it. It opens no port on the device. It adds no route. It needs no tun device and no
kernel module. There is nothing on the customer's network for anyone else to reach.
When an engineer wants a shell, the relay asks the device to join one session for one person.
The shell travels over a second outbound connection to the same relay, opened for that session.
When the session ends, that connection closes.
Who can get in, and how we check
Every step names a person and a device:
- The engineer logs in to the relay. The relay reads their role from the database on every request, not from an old token.
- The relay checks that the engineer's team owns the device, and that their role allows a shell. There are four roles: viewer, operator, admin, owner.
- The relay creates a session with a short-lived code, stored hashed.
- The device's own OpenSSH server checks the key. The device keeps its own list of trusted keys and accounts, and our servers cannot add to it. With our CLI the key is the engineer's own SSH key, and the private key stays on their laptop. With the browser shell, SSH runs in the browser with the engineer's own key, and the relay only forwards encrypted bytes. The agent refuses password sessions.
- The device's host key must match the one it reported the first time. If it changes, shells are refused until an admin accepts the new key. The CLI and the browser shell check it too, against the fingerprint the engineer pasted from the device.
- The session is logged: who, which device, when.
Remove someone from the team, or demote them to viewer, and their open shells end right away.
What the customer's IT sees
One outbound HTTPS connection from one device they did not buy, to one host, plus a second to the
same host while a shell is open. That is it.
No inbound rule. No new subnet. No client on their laptops. No change on their side when we add an
engineer or lose one. If they block the connection, we lose the shell, and nothing else of theirs
changes.
That is the sentence that gets through a security review: one shell, on one machine we shipped,
for one engineer we authorised, with a record of it.
What it does not do
We would rather say this up front:
- It is not a mesh VPN. The tunnel only reaches the device's SSH server. Once you have a shell, the device is still a machine on their network, so their network rules still apply to it.
- No session recording. The log says who and when, not what they typed.
- No uptime SLA, no SOC 2, no high availability.
- It needs OpenSSH on the device. Dropbear is not supported.
- It connects directly and does not use an HTTP proxy. A network where web traffic only leaves through a proxy will not work.
If you need to reach a whole site network, a VPN is the right tool. If you need a shell on the
machine you shipped, this is less to approve.
RescueShell: €0.10 a device a month, billed yearly, at least €6 a year, plus VAT. Thirty-day
trial, card required, and the clock starts when your first device connects. Hosted in the EU,
exceptions listed.
