Shellius is built around short-lived certificates: a bootstrapped host trusts the organization's CA, and nobody holds a long-lived key. Some machines cannot join that model — network appliances, customer-owned servers where you may not change sshd, legacy systems. The Keystore exists for those.

It is the one sanctioned exception to "zero static keys", and it is deliberate rather than a loophole. A key you keep in a wiki or on a laptop is invisible; the same key in the Keystore is encrypted, permissioned, audited, and still subject to the production approval flow. If a host can be bootstrapped, bootstrap it instead.

What it stores

Item	What it is
Identity	A username plus a password, an SSH key, or both. Reusable across many servers.
SSH key	A key pair, generated in Shellius or imported. An identity can point at one.
Export to servers	A record of pushing, rotating or removing a key on servers.

Every identity and key has a scope. Organization items are the shared Keystore described on this page. Personal items belong to one user and are covered in Personal vault.

How secrets are handled

• Private keys, passphrases and passwords are encrypted at rest with AES-256-GCM, and decrypted in memory only when a connection or deployment needs them, or on an explicit, audited export.
• List and detail views never return a secret. You see the public key, the fingerprint, and whether a password or passphrase is set.
• Secrets are never written to logs. Audit entries carry names, ids and fingerprints only.
• A passphrase-protected key stays passphrase-protected at rest, in addition to the encryption above.

Production still needs approval

Binding an identity to a server does not bypass anything. Connecting to a saved server goes through the access request flow whatever its authentication mode, so a prod server still needs an approver. See Access requests.

Required permissions

Permission	Default roles	Allows
keystore.view	Manager, Admin, Super admin	See identities, keys and deployments — never secrets.
keystore.test	Manager, Admin, Super admin	Test an identity against a saved server.
keystore.manage	Admin, Super admin	Create, import, edit and delete identities and keys; test against an arbitrary host.
keystore.export_private	Admin, Super admin	Download a stored private key in plain text. Always audited.
keystore.deploy	Admin, Super admin	Push, rotate and remove keys on servers.
servers.manage_credentials	Admin, Super admin	Switch a server to identity authentication and pick its identity.
servers.reset_host_key	Admin, Super admin	Clear a server's pinned host key.

Roles are editable, so your organization may differ — see Team and roles.

Add an SSH key

Open Keystore, make sure the scope is Organization, and select the SSH Keys tab.

To generate a key

1. Select Generate key.
2. Give it a name and choose a type. ED25519 is recommended; RSA (2048, 3072 or 4096 bits) and ECDSA (256, 384 or 521 bits) are available for hosts that need them.
3. Optionally set a comment and a passphrase, then save.

To import a key

1. Select Import key and paste the private key or choose a file.
2. If the key is encrypted, Shellius asks for its passphrase.
3. Optionally paste the matching public key, or an OpenSSH user certificate that certifies this key. Both are checked against the private key and rejected on a mismatch.

Import detects the format from the content, not the file extension:

Format	Notes
OpenSSH	Including bcrypt-encrypted keys.
PEM PKCS#1 RSA	Including legacy encrypted PEM.
SEC1 EC
PKCS#8	Plain and encrypted.
PuTTY .ppk	Versions 2 and 3.

Supported key types are ed25519, RSA and ECDSA. DSA keys are rejected. Imported keys are normalised to OpenSSH format.

Create an identity

1. On the Identities tab, select New identity.
2. Enter a name and the username to log in as.
3. Under Authentication, turn on Password, Private key, or both. For a key, pick one from the Keystore, or generate or import one in place.
4. Save.

With both enabled, the key is tried first and then the password. That also covers hosts configured to require both.

When you edit an identity later, leaving the password blank keeps the stored one. Clear stored password removes it.

Use an identity on a server

1. Open the server and edit it (this needs servers.manage_credentials).
2. Under authentication, choose Stored identity instead of Shellius CA certificate, and select the identity.
3. Save.

The server now counts as onboarded without the bootstrap script. Browser sessions connect with the identity; everything else — policies, approvals, session records — works as it does for certificate servers.

This is a browser route

Identity-based sessions are opened by the Shellius backend, so the backend is the machine that must be able to reach the host. See Network reachability.

Test an identity

From an identity's detail view, run a test against a saved server. The result shows whether login succeeded, how long it took, and the host key fingerprint the server presented.

Testing against a free-form host and port needs keystore.manage. Loopback, link-local (including cloud metadata addresses), unspecified and multicast targets are refused.

Export keys to servers

The Export to servers tab pushes a Keystore public key into authorized_keys on servers, removes it again, or rotates it.

1. Select Export to servers.
2. Key & action — choose the key and one of Export, Remove or Rotate. For a rotation, also choose the old key being replaced.
3. Servers — select the targets.
4. Authentication — either use each server's own access (its CA certificate, or its stored identity) or use a specific identity. Optionally set the target user, and enable Use sudo to write another user's authorized_keys.
5. Start the job. Each server reports pending, running, success or failed, and a failed server can be retried on its own.

A rotation deploys the new key, verifies that login works with it, and only then removes the old key. With Update identities to the new key enabled, every identity that used the old key is repointed to the new one.

Production targets

A key deployed to a production host is standing access with no approval behind it. If any selected server is prod, the job is refused unless your role holds access.prod_bypass and the organization switch that allows skipping production approval is on.

Export a private key

With keystore.export_private, a key's detail view can reveal the private key in plain text. Every export is written to the audit log as keystore.key.export, and the key records when it was last exported. Treat an exported key as out of Shellius's control from that moment.

Host key pinning

The first successful connection to a server pins its SSH host key. Every later connection checks it, and a mismatch refuses the connection rather than warning.

After a legitimate change — a re-imaged host, for example — open the server and choose Reset host key (servers.reset_host_key). The next connection pins whatever key the server presents, so confirm the change first.

Deleting

• A key that an identity still references cannot be deleted. Unlink it first.
• An identity bound to servers cannot be deleted unless you force it, which detaches those servers and returns them to certificate authentication.

Next steps

Quick ConnectOpen an ad-hoc session to a host you have not saved.Personal vaultPrivate identities, keys and hosts that only you can see.Bootstrap a hostMove a host onto certificates and retire its stored key.Audit logWhere Keystore changes, exports and deployments are recorded.