Security: what we protect, and what we do not

This page describes what the app actually does, not marketing. We list the limits too, so nothing is overstated.

The basic principle

LiveSSH connects over SSH from your device straight to the server you choose. Your connection details do not pass through a LiveSSH server.

If you turn on LiveSSH Cloud (paid), items such as hosts, snippets and SSH keys are encrypted on your device before they sync. The decryption keys can only be derived from your master password and your recovery key. This design is called end-to-end encryption, or zero knowledge.

How the vault is encrypted

Synced items are protected like this:

Items are encrypted on your device with XChaCha20-Poly1305 (authenticated encryption) using a randomly generated data key.
The data key is wrapped with a key derived from your master password using Argon2id (64 MiB of memory, 3 iterations).
The same data key is also wrapped separately with your recovery key, a 52-character base32 string from which a key is derived with HKDF.
The wrapped data keys are stored in a keyset (JSON) on the server.
Changing your master password only re-wraps the keyset. Your items stay as they are and the recovery key keeps working.

The recovery key

If you forget your master password, the recovery key opens the vault and lets you set a new master password.

If you lose both the master password and the recovery key, nobody can recover your data. The server does not hold the keys needed to decrypt it, so that includes us. You are responsible for keeping the recovery key safe.

What the server stores

The LiveSSH Cloud server is a self-hosted Supabase. This is what it holds:

Stored

Your email address from your Google or Apple account (you sign in only with Google or Apple; no login password is stored)
The keyset: the data key wrapped by your master password and by your recovery key
Ciphertext of vault items. The server can see each item's type (for example host, snippet, key), its ID, timestamps and deletion markers
For push: device tokens and device type, a hash (SHA-256) of the notification hook token with a label (the host display name), and your subscription expiry
Access logs (IP address, request time) for security and troubleshooting

Not stored

Your master password and recovery key
Any key that can decrypt your items
SSH passwords, private keys, host addresses and user names (they reach Cloud only as ciphertext)
Terminal input and output, command history, files you transfer over SFTP

The database separates accounts with row-level access control, and traffic to the server is protected with TLS. Retention periods and processors are listed in the privacy policy.

Host key pinning (TOFU)

When you connect to a server for the first time, the app shows its host key fingerprint (SHA-256) and, once you confirm, saves it with that host (Trust On First Use).

If the fingerprint later differs, the app refuses to connect and warns you. The server may have been replaced, or someone may be intercepting the connection. You can reset the saved fingerprint on the host's edit screen.

You still have to judge whether the fingerprint on the very first connection is genuine; TOFU does not protect against an attack during that first connection.

What a push notification contains

Push notifications travel a separate path from the encrypted vault. A notification hook on your server sends the notification to the LiveSSH server, which delivers it to your device through Google Firebase Cloud Messaging (on iOS via the Apple Push Notification service).

A notification contains a title, a body (for example the confirmation request text the agent produced, up to 300 characters), the tmux session name and the host label. On this path it is not end-to-end encrypted, so it passes through the LiveSSH server and Google or Apple. The server is built not to write notification bodies to its logs. If an agent's confirmation prompts could contain sensitive text, do not enable notifications.

Crash reporting

Crash reports are sent to Firebase Crashlytics only if you consent on first launch, and you can turn them off at any time under Settings → Security. Turning them off deletes reports that have not been sent yet.

A report contains the crash cause (stack trace), the OS and app version, and the device model. Error messages are cut to their first line and IP addresses, email addresses, paths and host names are masked before sending. Host addresses, user names, commands, terminal output, file names and keys are never included. The app uses no advertising SDK and no usage-analytics SDK.

What this design does not protect against

A device infected with malware, or an unlocked device, cannot be protected by the app. While the vault is open the app works with decrypted data, and if you enable biometric unlock the master password is kept in the device's secure storage.
A weak master password is vulnerable to brute-force guessing. Argon2id slows each guess down; it does not prevent guessing.
The LiveSSH server can see metadata such as item types, IDs, timestamps and the number of items.
Security on the SSH server side (key management, a compromised server, how the notification hook token is kept there) is up to you and your server's administrator.
The app's source code is not public and it has not been audited by a third party. The explanations on this page are written by the developer and have not been independently verified.

Reporting a security problem

If you find a vulnerability, or behaviour that differs from this description, write to contact@xiu.kr.

Last updated: 2026-10-07