Security model

Security is the point of SSH Ache, not a feature bolted on. Two layers matter: how the desktop app protects things locally, and how Teams / the cloud vault stay zero-knowledge.

On your machine

• Secrets in the OS keychain. Passwords, key passphrases, and private keys are stored in the platform keychain (Keychain / Credential Manager / Secret Service), not in plaintext on disk.
• Host-key verification. First-connect fingerprint confirmation, pinned in a local known_hosts store. A changed host key refuses the connection.
• No account, no upload. Using the app requires no sign-in. Local-only hosts never leave your machine.

Zero-knowledge cloud

When you opt into Teams or the personal vault, the server is designed so it cannot read your data — it stores ciphertext and wrapped keys, nothing more.

• Team key. Each team (and each personal vault) has a symmetric team key. Connections are encrypted ("sealed") under it before they leave your device.
• Wrapped to members. The team key itself is sealed to each member's public key (X25519). Only a member's device can unwrap it. Adding a member means an existing member wraps the key to the newcomer's key — the server never handles it in the clear.
• What the server stores. Ciphertext connections, per-member wrapped keys, and metadata needed to route sync. Not your credentials, not your session output.

Cryptography

SSH Ache uses audited @noble primitives:

• XChaCha20-Poly1305 for authenticated symmetric encryption,
• X25519 for key agreement and sealing keys to recipients,
• Ed25519 for signatures,
• Argon2id for deriving keys from your password.

Live view & audit

Live view is read-only and never silent — the watched session shows a watcher count. The Auditor role can review session history and presence for oversight without the ability to decrypt connection secrets.

Live-view mirroring

Watching a teammate's desktop session doesn't route their SSH through the cloud. The desktop keeps the SSH connection local and mirrors only the terminal output to the relay, which fans it out to viewers. The relay never sees the SSH secret or the typist's keystrokes — strictly less than the web-terminal path, where the relay opens the SSH session itself. Viewers are read-only; input is dropped. The relay's egress is also restricted to public targets (private, loopback, link-local and cloud-metadata addresses are refused) so it can't be pointed at internal infrastructure.

Reporting a vulnerability

Found something? Please report it via the GitHub repository. Responsible disclosure is appreciated.