This is the most security-sensitive part of Server Manager. Here's exactly what happens to your SSH credentials at every stage.
When you connect a server (no saving)
The default path: type your server IP, username, and password/private-key into the Connect modal, click Connect.
- Your credentials are sent over HTTPS to Server Manager
- They're held in process memory of the server-side session that talks to your VPS
- Nothing is written to disk. No database, no log file, no cache.
- When you disconnect, close your browser tab, or the session times out, the credentials are discarded from memory
If our server is rebooted, your credentials are gone — you'd need to reconnect manually next time. This is by design.
When you save a server profile (opt-in)
If you tick "Save this server" during connection, we encrypt your credentials with a passphrase only you know.
What gets encrypted
The encrypted blob contains your SSH password OR your private key + optional passphrase for the key. Plus a small metadata header so we know which credential type to use.
How encryption works
- You provide a passphrase at save time (we recommend something you'd use for nothing else)
- The passphrase is fed through scrypt — a deliberately slow password-based key derivation function — with a per-server random 16-byte salt, to produce a 256-bit AES key
- Your credentials are encrypted with AES-256-GCM (authenticated encryption — tampered ciphertext fails to decrypt, no padding-oracle attacks)
- We store the encrypted ciphertext, the salt, the GCM nonce, and the GCM authentication tag in the database
- Your passphrase is never stored. Not hashed, not derived, not present anywhere on our side.
How we tell "wrong passphrase" from "tampered data"
Both fail the same way: AES-GCM authentication-tag check fails. There's no stored verifier we can compare your passphrase against, no hash to leak. Wrong passphrase = decryption error = you re-enter and try again.
When you reconnect to a saved server
You paste your passphrase. We re-derive the key with scrypt + the stored salt, decrypt the credential blob, use the decrypted credentials to open the SSH session, then immediately discard the decrypted credentials from memory once the session is established.
The decrypted SSH credentials live only in the session-handling code for the lifetime of the SSH connection itself. Same as the no-save flow above — memory-only, no disk.
What happens if our server is compromised
This is the threat we designed against. Concretely:
- Attacker gets read access to the database: they get ciphertext. To use any saved credential, they need to brute-force the passphrase per server. - scrypt is intentionally slow — every passphrase attempt takes ~100ms+ of CPU time on modern hardware. Brute-forcing even a 6-character random passphrase takes years on a single machine, decades on commodity GPUs.
- Attacker gets full server compromise (RCE — remote code execution — during a live session): they could read decrypted credentials for users currently online. But they don't get access to saved-but-offline users' credentials.
- Attacker gets a database backup from last week: same as read access — they have ciphertext only.
What this means for you, in practical terms
The three scenarios above translate to very different real-world exposure:
- Database read or stolen backup (the most common kind of breach): the attacker gets encrypted blobs and nothing else. To actually use any saved credential they'd have to brute-force your passphrase, which scrypt makes infeasible for a strong one. Your servers stay safe.
- Full server compromise while you're actively connected (rare and severe): because an open SSH session needs your real credentials in memory, an attacker controlling our running process in that window could extract the decrypted credentials of users who are connected at that moment and use them to log into those users' actual servers. If you're offline at the time, your saved credentials are still just ciphertext to them — you're not affected.
The key property: even in the nightmare full-compromise case, the blast radius is limited to "whoever happens to be online during the attack," not "everyone who ever used Server Manager." Most catastrophic breaches expose every user's secrets at once; this design deliberately doesn't.
| Breach type | What the attacker gets |
|---|---|
| Database read (most common) | Ciphertext only — nobody's usable credentials |
| Stolen DB backup | Ciphertext only |
| Full live-session RCE (rare, severe) | Decrypted credentials of only users connected in that window |
This is meaningful protection against the most common breach pattern (data exfiltration), and it deliberately accepts that an attacker with full live-server compromise is a different, harder threat we don't claim to fully defeat — while still bounding even that worst case to currently-online users.
Strong-passphrase advice
The whole encryption scheme is only as strong as your passphrase. Recommended:
- At least 20 random characters, or
- Five random English words (à la "correct horse battery staple") — easy to remember, hard to brute-force
- Never reuse the passphrase you use for your laptop login, your password manager, or your email
- Don't share it. Server Manager itself doesn't need it — it's only between you and the encrypted blob.
If you lose the passphrase, the saved credentials are unrecoverable. You'd delete the saved server profile and re-add it from scratch.
Why we don't offer "passwordless" or "convenience" key access
A few products store SSH keys with no encryption ("trust us, we keep them safe") or behind only the user's account password. Server Manager doesn't. The passphrase mechanism is the line between "anyone with our database can SSH into your servers" and "anyone with our database needs to brute-force your passphrase first." We think that's worth the one-time inconvenience of choosing a passphrase.
What's NEVER sent or stored
- SSH private keys in plaintext to our database
- SSH passwords in plaintext to our database
- Your encryption passphrase — anywhere, in any form
- Decrypted credentials in any persistent storage — disk, logs, backups, cache
The only place decrypted credentials exist is in the live session's process memory, and only for the duration of the session.
Questions or concerns?
If anything in this article is unclear, or you have a specific security question about how your credentials are handled, reach out via Contact — we're happy to explain in more detail.