Manage an instance's password, SSH keys and hostname

The Access tab holds what you need to get into an instance: its user account and password, the SSH keys it receives, its hostname and its cloud-init settings. The tab also holds Rebuild operating system, which Rebuild an instance describes.

Each instance boots with a cloud-init drive. It holds the user account, password, SSH keys, hostname and network settings we keep for the instance, and cloud-init inside the operating system applies them as it boots. Most changes on this tab update that drive, so they 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 regenerate cloud-init. Both buttons stay disabled while it is stopped.
• The instance is not suspended or being moved to another host.
• To reset the password, the QEMU guest agent runs inside the instance. The Guest card on the Console tab shows Agent running 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 the image creates. 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 cloud-init keeps it when the instance next boots. The old password stops working at once. SSH keys keep working.

The SSH keys card sets the public keys cloud-init adds to the user account's ~/.ssh/authorized_keys.

1. Under Public keys, paste every key you want the instance to receive, one per line. Lines that start with # are ignored.
2. Select the save button. It counts the keys as you paste, such as "Save 2 keys".
3. Restart the instance with Restart in the header. Cloud-init adds the keys as the instance boots.

We cannot read the keys back, so the box is empty each time you open the tab. Saving replaces the whole list we hold, so paste every key you want each time. A rebuild clears the list: save your keys again after one, then restart.

1. On the Hostname card, type the new name under Hostname. Use letters, digits and hyphens, up to 63 characters, with no hyphen at the start or end. Dots are not allowed here.
2. To apply it straight away, tick Reboot now so the guest picks it up. The box is disabled while the instance is stopped; it takes the name when it starts.
3. Select Save hostname.

The dashboard and the host use the new name at once. Inside the instance, cloud-init sets it as the hostname on the next boot. The Name card on the Settings tab and Edit hostname… in the header's Instance actions menu change the same name.

The hostname does not create a DNS record. To reach the instance by a name in your own domain, see Manage an instance's addresses and names.

Regenerate cloud-init when the instance did not pick up a change, such as a primary address you attached.

1. On the Cloud-init card, select Regenerate cloud-init….
2. Select Regenerate cloud-init in the dialog. The message that follows names the network settings it wrote, such as ip=203.0.113.10/24 gw=203.0.113.1.
3. Restart the instance with Restart in the header.

Regenerating writes the user account, the password we hold, the hostname, the DNS resolvers and the instance's primary address into its cloud-init settings 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, its new hostname 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. Check the Guest card on the Console tab. If it shows Agent offline, 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.

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.

This is a private key. Paste the public key (.pub) instead.

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

Not an OpenSSH public key (expected "ssh-ed25519 AAAA… comment").

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.

Letters, digits and dashes only; up to 63 characters; no leading or trailing dash.

The hostname has a dot, a space or another character it cannot hold, or it is too long. Use one label, such as web-2.

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!

Cloud-init usually creates new SSH host keys on the first boot after you change the instance's 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"

PUT /api/v1/client/vps/{uuid}/ssh-keys replaces the keys we hold. 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"}'

PATCH /api/v1/client/vps/{uuid}/hostname sets the hostname. Send hostname, and reboot as true to restart a running instance straight away; it is false when left out. The response is {"hostname": "web-2", "rebooted": true}, where rebooted repeats what you sent. A name the rules above refuse answers 400 with Invalid hostname.

curl -X PATCH https://api.coritan.com/api/v1/client/vps/$INSTANCE_UUID/hostname \
  -H "Authorization: Bearer $CORITAN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"hostname": "web-2", "reboot": true}'

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"}. 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 ssh-keys, hostname and cloud-init/regenerate. While we move the instance to another host, every request that changes it answers 409 with Instance is migrating.