SSH keys

Provisioning turns off password authentication, so the only way onto a machine is a key in the deploy user’s authorized_keys. Shipways owns that file and rewrites it whenever the set changes. Add the public half — the one ending in .pub. Never paste a private key.

​

Two places to add one

On a single server, from its Settings tab. The key reaches that machine and nothing else. Across the organization, from SSH keys in the organization’s settings. The key goes onto every server the organization owns, including ones connected later. That last part is the reason to use it: a colleague added once does not have to be added again for every machine somebody spins up next month.

​

Shipways’ own key

Always present, and not shown in the list. Removing it would leave the panel unable to reach the machine, so it is not offered. When something else removes it anyway, see locked out.

​

Removing a key

The person stops being able to sign in as the deploy user on every server the key was on. Anything they left running keeps running — this is about access, not about processes. Removing an organization-wide key removes it everywhere at once, including servers connected after it was added.

​

What a key does not grant

Signing in is the deploy user’s shell, which has sudo. That is effectively root on the machine. Inside the panel, opening a shell is its own permission, held separately from being allowed to change a server. An SSH key added here bypasses that distinction entirely — it is access to the machine, not access to Shipways. Treat the list as the list of people who have root on your fleet, because it is.

​

Deploy keys are different

A site’s deploy key is a key the server uses to clone from your repository. It goes on the repository, not on the machine, and it reaches that one repository and nothing else.