Security

Only what is built and tested today is listed here. If a property is not on this page, assume we do not have it.

The connection

• The agent dials out over HTTPS. The installer refuses a relay address that is not https://. The device opens no port.
• Our agent, CLI and browser shell carry shell traffic over a WebSocket only, so session handles never land in URLs or proxy logs.
• Unauthenticated handshakes are size-capped before anything is parsed.
• Login, signup, provisioning and shell handshakes are rate-limited per source before they reach the database.

Your team's data

• Most requests run under the database's row-level security, plus team checks in code. Sign-in, device connections, billing and jobs that span teams rely on the code checks. Team A cannot see team B.
• Four roles: viewer, operator, admin, owner. Every route is denied unless it declares what it needs. Your role is read from the database on each request, not from an old token.
• Removing someone, or demoting them to viewer, ends their open shells right away.
• No shared keys. Each provisioning credential belongs to one team. Refresh tokens are stored hashed.

Shell access

• Each shell is a session with a short-lived code, stored hashed. Every failed check gets the same refusal.
• The device keeps its own list of trusted keys and accounts. Our servers cannot add a key or an account to it. A new install has to be given that list and refuses to run without it. If our servers were compromised, they still could not add a key or an account on a device.
• Before it connects anything, the device asks your key to sign a fresh challenge. Our servers hold no key, so they cannot answer it, and a signature cannot be reused for another session.
• With the CLI, you log in with your own SSH key. Your private key never leaves your laptop.
• The CLI and the browser shell check the device's host key. You paste the fingerprint the device printed on the first connection, and a later change is refused. The relay also records the key it first sees and refuses shells if it changes, until an admin accepts the new key.
• The browser shell runs SSH in your browser with your own key, saved encrypted by your passkey or loaded from a file for one session. The key goes into a separate, signed frame. The relay only forwards encrypted bytes and cannot read the session.
• Shells use SSH keys. The agent refuses password sessions.

Accounts

• New accounts must verify their email. Login, reset and invites are rate-limited and answer the same for known and unknown addresses.
• Logging out ends the session on the server, not just in your browser. A password change ends your other sessions.
• Optional two-factor login with an authenticator app and single-use recovery codes.

Records and control

• Admins see a log of who opened a shell on which device, and when.
• Key changes, host key accepts, and refused sessions are recorded. Fingerprints only, never key bodies.
• We can suspend a team and end all its sessions in one step.
• Card details go to Stripe. They never touch our servers.

Where it runs

The app and relay run in Azure West Europe (Netherlands). The database and its backups are in Azure North Europe (Ireland). Both are EU regions. The EU residency page names every service that touches your data.

Not offered

No uptime SLA, no SOC 2, no session recording, no audit export, no high availability. This list changes when the product does.

Found a problem? Mail support@rescueshell.com.