Let developers onto the box

$ grim server:dev:keys add dev1 --key=~/keys/anna.pub --label=anna

Everyone on a dev box logs in as the same dev user, so access is a matter of whose public key is in that user's authorized_keys. grim server:dev:keys is for the day someone joins the team, the day someone leaves, and the day someone gets a new laptop. Each key goes in under a label, and the label is what you remove it by later.

It is grim server:keys with dev as the default user. Nothing else differs.

Usage

$ grim server:dev:keys list dev1                                       # who is in
$ grim server:dev:keys add dev1 --key=~/keys/anna.pub --label=anna     # from a file
$ grim server:dev:keys add dev1 --key="ssh-ed25519 AAAA…" --label=ben  # from a pasted key
$ grim server:dev:keys remove dev1 --label=ben                         # out again

Run it from anywhere on the machine that ran grim server:dev:setup. The server is looked up in your ~/.grim/servers.json by address or alias, and the connection is made with the login setup bootstrapped with, not as dev. So it is the person who raised the box who manages its keys.

Arguments and options

Manage SSH keys for the shared dev user on a dev VPS (alias of server:keys --user=dev)

Usage

grim server:dev:keys [--user USER] [--key KEY] [--label LABEL] [--] <action> <host>

Arguments

Options

What it actually does

1. list reads /home/dev/.ssh/authorized_keys and prints a label and a SHA256 fingerprint for each managed key. The fingerprint has the form ssh-keygen -lf prints, so a developer can check theirs against it.
2. add reads the key from the file, or takes the string as it is when it starts with a key type. It writes two lines to the end of the file: # grim-key:<label> and the key. A key already stored under that label is replaced, so rotating a key is one add with the same label.
3. remove deletes the label line and the key under it. When the label is not there it says so and changes nothing.

After every write the file is owned by dev again, with mode 600. Lines without a label above them are never touched.

Pitfalls

list does not show every key that works

Only labelled entries are listed. The key setup put there, yours or the ones from --dev-keys, has no label, so a fresh box answers No managed keys for dev yet. while you log in fine. The same goes for anything added by hand. To bring such a key under management, add it again with a label and delete the bare line on the box.

Removing a label does not end an open session

remove stops the next login. A terminal or an editor that is already connected stays connected until it closes. When someone leaves on bad terms, also end their sessions on the box.

Labels cannot contain a colon

Label must not contain newline or colon. A name, a nickname or anna-laptop all work.

After it finishes

The developer can log in as dev. Send them the block that grim server:dev:ssh-config prints, and they attach their editor. The whole onboarding, from asking for the key to the first open project, is the recipe Set up a dev box for a client.

Questions

Can I use it for another user on the box?

Yes, with --user. It manages /home/<user>/.ssh/authorized_keys for any existing account with a home under /home. For the deploy user of a production server, grim server:keys has that as its default.

Does every developer need their own key?

Yes. One label per person and device is what makes removal possible. A shared key can only be taken away from everyone at once.

Related spells

Recipes that use it