SSH keys: managing access to your instances

SSH keys are how Lite controls login access to your instances. Keys live in a per-account key pool (Compute → SSH Keys) and are attached to instances at deploy time. Linux images ship with password authentication disabled, so an SSH key is required to get in — there is no fallback password to fall back on.

What the SSH Keys page supports

• Add Existing Key — paste a public key you already have. Accepted formats: ssh-rsa, ssh-ed25519, ecdsa-sha2-* (RSA 2048/4096 and ed25519 are the practical choices today).
• Generate New Key — Lite generates a key pair for you. RSA pairs are generated in your browser with Web Crypto when supported; ed25519 is generated server-side.
• Delete a key — removes it from the pool. Existing instances that already have the key in authorized_keys are not affected (the deletion only stops the key from being attached to future deploys).

Choosing a key type

• ed25519 — recommended default. Small, modern, fast, secure.
• RSA 4096 — broadly compatible if you need to support older tooling.
• RSA 2048 — acceptable but on the lower end of what we recommend.
• DSA / ECDSA — accepted by the paste field for legacy reasons; not recommended for new deployments.

# Generate locally with OpenSSH if you prefer
ssh-keygen -t ed25519 -C "[email protected]"

Attaching keys to instances

When you deploy a VM (Compute → Cloud → Create), the form lets you select one or more SSH keys from the pool. The selected public keys are baked into the instance during provisioning. Multiple keys per instance is supported — useful when more than one person legitimately needs access.

There is no "default key for every future instance" toggle — each deploy picks its keys explicitly. This is intentional: it keeps key blast radius small if any single key is compromised.

When you generate a new key in the portal

Lite shows the private key exactly once at the end of the generate flow. Copy or download it immediately and store it somewhere safe (a password manager is ideal). We do not keep a copy of your private key — once you close the dialog there is no way to retrieve it. The corresponding public key stays in the pool.

Lost private key — recovery via VNC

If you lose access to a private key, you cannot SSH back in — but the instance is not lost. Open the VNC console for the instance from the dashboard, sign in at the OS prompt, and either add a new public key to ~/.ssh/authorized_keys or repair the configuration. The console connects below SSH, so it stays reachable even when remote access is broken.