How it works

A small agent on the device dials out to our relay. You ask the relay for a shell. Nothing connects in to the customer's network.

1. Your device On the customer's network. Opens the connection.
2. outbound TLS, port 443
3. The relay Azure West Europe. Checks your login and role.
4. your login, over HTTPS
5. You Browser shell or the CLI.

Both ends connect out to the relay. Nothing connects in.

The agent

One static Go binary, built for amd64, arm64, armv7 and armv6. It needs no kernel module and no tun device, and it opens no port. It holds one outbound connection to the relay and reconnects on its own when that drops. Read-only root filesystems are fine.

The relay

The relay is where your login, your team and your role meet the device. It checks who you are, which team owns the device and what your role allows, then joins your session to the device. It keeps the log of who opened a shell on which device, and when.

Opening a shell

1. You log in and pick a device, in the browser or with rescueshell.
2. The relay checks your role and creates a session with a short-lived code.
3. The relay asks the device to join that session, over the connection the device already holds.
4. The device's own SSH server checks your SSH key. The device only accepts keys from its own trusted list, which our servers cannot add to. The agent refuses password sessions. The device's host key must match the one it reported first.
5. The session is logged.

What the customer's IT sees

There is no VPN, so there is no route between your network and theirs. Their firewall sees one outbound TLS connection on 443, the same kind a browser makes. Through it you can reach one shell on one device you shipped, as one operator the relay allowed. Nothing else on their network is addressable.

What you need on the device

• Linux on amd64, arm64, armv7 or armv6.
• sh, curl, tar, OpenSSL 3 and an OpenSSH server. Dropbear is not supported.
• Outbound HTTPS to the relay.

Install steps are in Add a device.