Security
How K2Shell protects credentials and controls server access.
Vault encryption, temporary credential processing and SSH certificate access have different trust boundaries. Here is how they work.
Two ways to connect
| Connection | Setup and authentication | Everyday use |
|---|---|---|
| Keyless SSH | Run the enrollment script on your Linux server, using root/sudo or the supported per-user setup. Verify the host key. Your account's certificate authority authenticates the chosen login user. | Browser workspace and AI agents. No server password to enter; fresh SSH certificates normally expire in five minutes. |
| Password-based SSH | Add an SSH host and unlock your encrypted vault. The server must accept password authentication. Private-key SSH is also available. | Browser terminal and files. Plaintext passwords are processed in memory, not persisted on K2Shell's servers. Saved vault passwords are stored as encrypted ciphertext. Agents use enrolled servers instead. |
SSH must be reachable from K2Shell. Password-based credentials travel over HTTPS to K2Shell for authentication. Read the security model before connecting.
Agent permissions, approvals and revocation
What access does my AI agent have?
Only enrolled servers in its scope, within both server and connection policies and the remote login user's permissions. Full access permits commands, terminals and files; an allowlist permits restricted diagnostics; read-only permits listings and monitoring data, not shell commands. Agents perform real operations. Per-action approval depends on your AI tool; K2Shell does not provide a universal approval gate.
How can I revoke access?
In Account, API keys & MCP, delete the key or disconnect the app to refuse subsequent authenticated calls. This does not undo changes or guarantee running jobs and sessions stop. Close active sessions and stop jobs separately. To remove certificate trust entirely, remove the enrollment trust configuration on the remote server, with administrator help where needed.
K2Shell records command text, target and result in Activity. Avoid including secrets in command text. Retained output is optional and sealed to your vault output key. Interactive recording is configured separately. Default HTTP request logs omit request bodies and redact authorization and cookie headers; infrastructure logging must be reviewed separately.
The vault is zero-knowledge
master password
└─ PBKDF2-HMAC-SHA256, 600,000 rounds
└─ key-encryption key
└─ AES-256-GCM wraps a random vault key
└─ AES-256-GCM encrypts each item
(item id bound as associated data)- Never sentYour master password stays in the browser. The server stores ciphertext and a salt.
- Recovery is yoursAn optional recovery code wraps the same vault key. Nobody else can reset it, by design.
- Used once, in memoryTo connect to a vault host, the browser decrypts that credential and sends it over HTTPS for that one connection. It is never written to disk.
What the server can see
| Data | Stored as |
|---|---|
| Hosts, passwords, private keys, snippets, history | Ciphertext only the vault can open |
| Kept command output | Sealed to a key whose private half lives in your vault |
| Session recordings, server backups | AES-256-GCM with the server's master key |
| SSH CA private keys, TOTP secrets | AES-256-GCM with the server's master key |
| Account password | Argon2id hash |
| API keys, session and OAuth tokens | SHA-256 hash |
| Email, server names and addresses, activity log | Readable, to run the service |
Agents never hold a key
One CA per account
An ed25519 certificate authority per account, sealed at rest. Enrolled servers trust only your account's principal for the login user you chose.
Five-minute certificates
Every connection gets a fresh key and a certificate that expires in five minutes, with only the extensions it needs.
Pinned host keys
The install script reports the server's host key over HTTPS, so it is pinned at enrollment. Install links work once and expire in an hour.