# Create, save, and delete SSH keys How the one-time private key reveal works when you generate or import an SSH key, and what deleting a key actually affects. 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. _Interface illustration: SSH keys list page: Name, Algorithm, and Fingerprint columns, the New Key button, and per-row rename and delete actions_ ## Before you begin - **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_keys` line). ## Generate a new key 1. On the **Compute > SSH Keys** page, select **New Key**. 2. In the dialog's name field, confirm or edit the key name. The dashboard prefills a default name, formatted like `ssh-key-20260829-1234`. 3. Leave the mode selector on **Generate new** (selected by default). 4. 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." _Interface illustration: New SSH key dialog, form stage: name field, Generate new / Import existing public key toggle, Create button_ 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. 5. 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. 6. Check **I have saved my private key**. This checkbox gates whether the next button is clickable. 7. Select **Done**. _Interface illustration: Save private key dialog, reveal stage: warning text, public and private key fields each with a copy button, Download private key button, 'I have saved my private key' checkbox, Done button_ 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. ## Where the private key goes after you close the dialog "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](/compute/access/web-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. ## Import an existing public key 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. 1. On the **Compute > SSH Keys** page, select **New Key**. 2. In the dialog's name field, confirm or edit the key name. 3. Switch the mode selector to **Import existing public key**. 4. Paste the OpenSSH-format public key into the public key field (a single `authorized_keys` line). 5. 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. ## Rename an SSH key 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." ## Delete an SSH key > [!CAUTION] > Deleting a key only affects whether it can be used to create *new* instances. > It does not affect instances that are already using it to sign in. An instance > whose `authorized_keys` file already contains the matching public key keeps > its access even after you delete the SSH key record — this direction gets > reversed often. 1. In the **Compute > SSH Keys** list, find the row for the key and select **Delete**. 2. 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." 3. Select **Delete** to confirm. _Interface illustration: Delete SSH key confirmation dialog: title, confirmation text including the key name, Delete button_ | 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 | ## When creation fails 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. ## Related documentation - [Instance access](/compute/access/) - [Use Web SSH](/compute/access/web-ssh/) - [Create an instance](/compute/instances/create/)