SSH keys

Every remote thing KamalCloud does is reached with one of two key pairs. They are not made at signup: generate them on Account → Access keys when you need them, or paste in private keys of your own.

• Control key — reaches runners and does the administrative work.
• Deploy key — what lands on servers, and what Kamal uses to reach them.

Both are held encrypted. The private halves are never shown, never downloadable and never sent anywhere but to the SSH connection that needs them.

Keyrings

Keys are pushed to each provider’s own keyring, per connection. Two projects at one provider are two keyrings, so the same key material is uploaded to both under the same name. That is what makes a newly built machine trust KamalCloud from its first boot: the provider installs the public halves for root.

The Account → Access keys page shows both keys, their fingerprints, and which connections each has actually reached.

Self-hosted connections have no keyring to push to. Registering a machine only reads it; the key goes on with the one-line command or a password install, below.

An existing machine

A machine built before the keys existed, or built outside KamalCloud, will refuse them. Two ways in:

The one-line command. The server’s SSH key page prints a command to paste into a console on the machine. It appends the public half to authorized_keys. Nothing in it is secret and nothing comes back; the install link is short-lived all the same.

Provider access. Where the provider will hand back a root password – Hetzner today – KamalCloud asks for one, uses it for exactly one session to install the key, and never reuses it. Nobody has to know the password. The only way to get one is for the provider to set a new root password, and that new password stays set on the machine; KamalCloud wipes its own copy once the install finishes.

A root password you know. Type it in, and KamalCloud uses it the same way: one session, then its copy is wiped.

Importing a key of your own

For a machine that already trusts a key you have, paste the private half under Account → SSH keys and name it. Then set that key on the server. Blank on a server means “the account’s deploy key”; a name means “this key, which the machine already accepts”.

Imported keys belong to a machine rather than to a keyring – they are not pushed to providers.

Host keys

KamalCloud verifies host keys. When a provider recycles an address, the old entry is forgotten as part of destroying the machine, so the next connection to that address does not fail on a mismatch.

A host key that changes underneath you – a rebuild done outside KamalCloud, for instance – will stop connections until you remove the server from KamalCloud and register it again. That is the intended behaviour: a changed host key on an address you did not expect to change is worth stopping for.