The Compute > SSH Keys page is where you create, rename, and delete SSH keys for signing in to instances and for use during instance creation. Creating a key offers two modes: have the dashboard generate a key pair, or import a public key you already hold.
Only the "Generate new" mode produces a private key, and that private key is shown exactly once, at the moment it is generated. Once you close the dialog, neither the dashboard nor the API has any way to retrieve it again — it is not hidden somewhere, there is simply no viewing path left. Before you select Create, decide where the private key will live: a password manager, an encrypted local file, or another place you trust.
- Permissions: your role must include SSH key management permissions.
- A place to store the private key: if you plan to use "Generate new", have a password manager or other secure storage ready before you start — there is no way back once the key is generated.
- An existing public key (optional): if you plan to import instead of generate, have the OpenSSH-format public key text ready (a single
authorized_keysline).
- On the Compute > SSH Keys page, select New Key.
- In the dialog's name field, confirm or edit the key name. The dashboard prefills a default name, formatted like
ssh-key-20260829-1234. - Leave the mode selector on Generate new (selected by default).
- Select Create. The dashboard generates an Ed25519 key pair on the spot, and the dialog switches to the "Save your private key" screen with the warning: "The private key is shown only once. Once closed, it cannot be retrieved again — save it now."
At this point the private key already exists — the dialog is just still open. The remaining steps decide whether you can ever see it again.
- Select Download private key to save it as a file, or use the copy button next to the public and private key fields to paste the content into a password manager.
- Check I have saved my private key. This checkbox gates whether the next button is clickable.
- Select Done.
This dialog cannot be closed by clicking the backdrop or pressing Esc — the only way out is checking the confirmation and selecting Done. This is not an oversight. The private key gets exactly one viewing, and the platform does not leave an accidental exit that a stray click could trigger.
"Cannot be retrieved again" describes what you can see. It is easy to read that as "the private key is gone from the system." What actually happens is narrower:
| What happens | What does not happen |
|---|---|
| Once the dialog closes, neither the dashboard nor the API has any path back to the private key in plaintext | The private key is not actually deleted from the system — the server keeps an encrypted copy |
| That encrypted copy is reused by the automatic-login feature in the web console SSH panel: opening the Web SSH panel matches the public key fingerprint and decrypts this copy for passwordless sign-in | That copy is never returned to you or anyone else through any API response — it is used server-side only and never appears in a response body |
| The only way to purge the server's stored copy is to delete the SSH key | Closing the dialog by itself does not trigger any server-side cleanup — whether the copy still exists has nothing to do with whether you closed the dialog |
If what you need is not "I can no longer see it" but "the server no longer holds a copy either," deleting the SSH key is the only way to get there — see below.
If you already have an SSH key pair locally, importing the public key skips the reveal step entirely. The private key stays on your own machine the whole time — the server never generates or holds it.
- On the Compute > SSH Keys page, select New Key.
- In the dialog's name field, confirm or edit the key name.
- Switch the mode selector to Import existing public key.
- Paste the OpenSSH-format public key into the public key field (a single
authorized_keysline). - Select Create.
The create response in import mode never includes a private key field. That is a separate fact from the one-time reveal rule for generated keys — do not conflate the two.
The name is only a label for your own reference. Renaming does not affect the key itself or any instance already using it. The name cannot be left blank — submitting an empty name shows: "Name cannot be empty."
- In the Compute > SSH Keys list, find the row for the key and select Delete.
- The confirmation dialog is titled "Delete SSH Key" and reads: "Are you sure you want to delete "
{{name}}"? This cannot be undone. Instances already using this key are unaffected, but it can no longer be used for new instances." - Select Delete to confirm.
| What happens | What does not happen |
|---|---|
| The key disappears from the list of SSH keys available when creating new instances | Instances that already have the matching public key in authorized_keys do not lose access |
| If the key was server-generated, the server's encrypted private key copy is purged along with it | The dashboard does not warn you up front which instances use this key — check that yourself before deleting |
Submitting with a blank name, or with "Import existing public key" selected and an empty public key field, fails with: "Failed to create, please check your input." Check the name and public key fields, then submit again.
[!NOTE] Two-step verification recovery codes have their own viewing-limit rules, which are not the same as the SSH private key rule on this page — do not assume they behave identically. The details belong to a separate page,
account/two-step-verification, which has not been written yet.