Security & privacy

The boundaries that protect the local vault, enrolled Cloud devices, live SSH credentials, and anonymous product analytics.

Local vault

The master password is processed with Argon2id to derive the key for AES-256-GCM authenticated encryption. Each vault uses a random salt and nonce. Decryption fails if the ciphertext or authenticated metadata has been changed.

A cached session is machine-bound defense in depth and expires after 30 minutes of idle time. It is not a replacement for operating-system account security or full-disk encryption.

SSH trust and credentials

Native SSH connections verify host keys. On first use, compare the fingerprint to a trusted value for that server. Private keys stay at their configured filesystem path unless you explicitly include their contents in a Cloud push. Clipboard copies use timed clearing when the platform supports it.

Cloud boundaries

Cloud server records use AES-256-GCM. Browser devices use P-256 keys and authorized workspace envelopes. The Cloud Access Phrase is processed on the device with PBKDF2-SHA256 at 600,000 iterations so a new enrolled device can unlock authorized workspace keys.

For browser SSH, the gateway needs decrypted authentication material briefly to establish the upstream connection. It receives this over TLS, keeps it in memory during setup, and does not write it to PostgreSQL or service logs. First connections still require host-key verification.

Anonymous installation telemetry

Released versions send one best-effort installation registration per version so maintainers can distinguish completed first-run usage from GitHub archive downloads. The payload contains only:

  • A randomly generated installation UUID stored in ~/.ssher/telemetry.json.
  • Operating system and CPU architecture.
  • ssher version and the generic installation source.

It does not contain commands, server names, addresses, SSH usernames, vault data, account email, hostname, or device name. The API stores no IP address in the installation ledger.

↘
Opt out before running ssher.

Set SSHER_DISABLE_TELEMETRY=1 in your environment. The CLI will skip installation registration and continue normally.

macOS and Linux

export SSHER_DISABLE_TELEMETRY=1

Windows PowerShell

$env:SSHER_DISABLE_TELEMETRY = "1"

Website analytics

The public website and ssher Cloud use one Google Analytics 4 property to understand page usefulness and product adoption across getssher.com and cloud.getssher.com. Analytics storage is disabled until you choose “Allow analytics.” Advertising storage, Google Signals, and advertising personalization remain disabled.

Page locations are deliberately stripped of query strings and URL fragments before measurement, preventing sign-in links, invitation tokens, and other access parameters from being sent. Product events use coarse names such as install method, selected plan, opened workspace area, or new versus resumed terminal. They never include commands, terminal output, server names or addresses, credentials, email addresses, team names, access phrases, or tokens. Your choice is stored for 180 days in a first-party preference cookie shared by the two ssher subdomains.

↘
You stay in control.

Choose “No thanks” in the analytics notice to keep analytics storage disabled. Clear the ssher_analytics_consent cookie to make the notice appear again.

Report a vulnerability

Do not open a public issue for a suspected vulnerability. Follow the private reporting instructions in the repository’s SECURITY.md.