Manage an instance's password and SSH keys

The Access tab holds what you need to get into an instance: its user account and password and the SSH keys it receives. Under Advanced, it can write the account and network settings to the instance again. The tab also holds Rebuild operating system, which Rebuild an instance describes. The hostname is on the Settings tab.

We keep the instance's user account, password, SSH keys, hostname and network settings, and the operating system applies them as it starts. Most changes on this tab reach the operating system the next time you start or restart the instance from the dashboard. A password reset is the exception: it works at once.

• The instance is running, to reset the password or reapply its settings. Both buttons stay disabled while it is stopped.
• The instance is not suspended or being moved to another host.
• To reset the password, the guest agent runs inside the instance. Open Advanced on the Console tab: the System report card shows Reporting when it does.

In the dashboard, go to Cloud Compute, open the instance and select the Access tab.

The User account card shows the account we set up when the instance was created. Username is the name to sign in with; Copy username copies it. Password reads Set when we hold a password for the account. We store it encrypted and never show it again after we set it, including the one the instance was created with.

1. On the User account card, select Reset password….
2. Select Reset password in the dialog.
3. The card shows the New password. Select Reveal to read it, or Copy all to copy the username and password together.
4. Store the password somewhere safe, then select I have saved them.

We set a new random password for the account inside the running instance, and the instance keeps it when it next starts. The old password stops working at once. SSH keys keep working.

The SSH keys card shows the public keys the instance receives. We add them to the user account's ~/.ssh/authorized_keys.

1. Under Public keys, add a key on a line of its own, or delete the line of a key you no longer want. Lines that start with # are ignored.
2. Select the save button. It counts the keys in the box, such as "Save 2 keys", and stays disabled until you change the list.
3. Start or restart the instance from the header. It installs the saved keys as it boots.

Saving replaces the whole list with what the box holds. If we cannot read the instance's keys, the box starts empty and the hint under it says so. Saving then replaces every key, so paste all the keys you want to keep. A rebuild keeps the list, and the rebuilt instance receives the keys when it first boots.

Reapply the settings when the instance did not pick up a change, such as a primary address you attached. The Advanced card explains the step in one line: it uses cloud-init, the tool that sets up the account, password, hostname and address when the instance starts.

1. On the Advanced card, select Reapply settings….
2. Select Reapply settings in the dialog. A message confirms Settings reapplied. Restart the instance to use them.
3. Restart the instance with Restart in the header.

Reapplying writes the user account, the password we hold, the hostname, the DNS resolvers, the instance's primary address and its IPv6 address to the instance again. It leaves the SSH keys as you last saved them.

The User account card shows Password as Set, and the instance accepts the new password straight away. After the next restart from the header, the instance has your SSH keys and its current network settings.

Cloud Compute instance must be running to reset password

Start the instance from the header, wait until it reads running, and reset again.

Could not reset the password: Internal server error

The guest agent inside the instance did not answer. Open Advanced on the Console tab and check the System report card. If it shows Not reporting, sign in with an SSH key and install the agent, as Use an instance's console describes. Without a key or a password, set one from rescue mode.

We could not read the current keys, so saving replaces every key on the instance.

The host did not answer when the tab opened. Reload the page to try again. To save now, paste every key you want the instance to keep.

Could not save the SSH keys

Add the key from inside the instance instead. Sign in on the console or over SSH, and append the key as a new line to ~/.ssh/authorized_keys.

Paste the public key from the .pub file instead of this private key.

You pasted the private half of the key pair. Paste the contents of the file that ends in .pub.

This line is not an OpenSSH public key, which looks like "ssh-ed25519 AAAA… you@laptop".

The line is not a public key in OpenSSH format. Keys from PuTTYgen need converting: copy the key from the box headed "Public key for pasting into OpenSSH authorized_keys file" in PuTTYgen.

Permission denied (publickey) after you saved keys

The instance has not booted since you saved them. Restart it from the header; a reboot typed inside the instance does not apply the keys.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

The instance usually creates new SSH host keys on the first start after you change its keys, password, hostname or network settings. Remove the old entry with ssh-keygen -R 203.0.113.10 and connect again.

• Connect to an instance over SSH
• Use an instance's console to sign in with the password when SSH does not answer.
• Rebuild an instance to start again from a fresh image.

GET /api/v1/client/vps/{uuid}/credentials returns the account without its password:

{
  "username": "ubuntu",
  "password_stored": true,
  "updated_at": "2026-09-16T10:42:00"
}

updated_at is when the instance's record last changed, for any reason.

POST /api/v1/client/vps/{uuid}/reset-password sets a new random password and returns it once, as {"password": "…"}. It needs no body. An instance that is not running answers 400 with Cloud Compute instance must be running to reset password.

curl -X POST https://api.coritan.com/api/v1/client/vps/$INSTANCE_UUID/reset-password \
  -H "Authorization: Bearer $CORITAN_TOKEN"

GET /api/v1/client/vps/{uuid}/ssh-keys returns the keys the instance receives, as one string with a key on each line, and how many keys that is:

{
  "ssh_keys": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExample alex@example.com",
  "count": 1
}

ssh_keys is an empty string when the instance has none. When the host does not answer, the request answers 502 with We could not read the keys from the instance. Try again in a moment.

PUT /api/v1/client/vps/{uuid}/ssh-keys replaces the keys the instance receives, so start from what the GET returns. Send ssh_keys as one string with a key on each line; an empty string clears the list. The response is {"status": "ok", "keys_set": true}, with keys_set false after clearing.

curl -X PUT https://api.coritan.com/api/v1/client/vps/$INSTANCE_UUID/ssh-keys \
  -H "Authorization: Bearer $CORITAN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"ssh_keys": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExample alex@example.com"}'

POST /api/v1/client/vps/{uuid}/cloud-init/regenerate rewrites the cloud-init settings and answers {"status": "regenerated", "ipconfig0": "ip=203.0.113.10/24,gw=203.0.113.1,ip6=2001:db8:1000:5::1/64,gw6=fe80::1"}. The ip6 and gw6 parts are there when the instance has IPv6, and ipconfig0 is null when the instance has no address attached. Restart the instance afterwards with the reboot power action.

A suspended instance answers 403 with Instance is suspended to PUT ssh-keys and cloud-init/regenerate; you can still read its keys. While we move the instance to another host, every request that changes it answers 409 with Instance is migrating, and so does reading its keys.