Grant or revoke deploy access

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

Everything grim does on a production server after setup, it does as the deploy user: releases, .env changes, logs. Who may do those things is decided by one file, that user's authorized_keys. When a colleague joins the project, when a freelancer's contract ends, when somebody's laptop is stolen, this is the command you need. It keeps each key under a label, so that taking access away is as exact as giving it.

Usage

$ grim server:keys list vps1                                          # labels and fingerprints
$ grim server:keys add vps1 --key=~/keys/anna.pub --label=anna        # from a file
$ grim server:keys add vps1 --key="ssh-ed25519 AAAA… anna" --label=anna
$ grim server:keys remove vps1 --label=anna

Run it from anywhere. The server must be in your ~/.grim/servers.json, and you must be able to log in with the account grim server:setup bootstrapped it with. --key takes a path or the whole public key as a string.

Arguments and options

Manage SSH keys for a service user on a server (default: deploy)

Usage

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

Arguments

Options

What it actually does

It connects with the bootstrap login, root or the --user that setup was given, because one account's authorized_keys cannot be edited from another without root.

1. list reads /home/deploy/.ssh/authorized_keys and prints every labelled key with its SHA256 fingerprint.
2. add checks that the key looks like an OpenSSH public key, then appends it under a marker line, # grim-key:anna. A key already stored under that label is replaced, which makes rotating a key a single command.
3. remove deletes the marker and the key below it. When the label does not exist it says so and changes nothing.

After every change the file is given back to the user with mode 600. Lines without a marker are never touched.

Pitfalls

list does not show every key that can log in

It shows the labelled ones. A key somebody pasted into the file by hand, or one the hosting image put there, opens the account all the same and appears nowhere. When access must be closed for certain, read the file itself on the server.

The label operator is you

Setup stores the key of whoever ran it under operator. Remove it and releases from your own machine stop working, although the bootstrap login still gets you in to add it back.

Deploy access is not enough to run this

A colleague whose key opens only the deploy account cannot manage keys. The command would fail at the connection. Granting access stays with those who hold the bootstrap login, which is the point.

The server is not on record

Unknown host "vps1". means your servers.json has no server under that alias or address. Keys can only be managed from a machine whose servers.json knows the server.

After it finishes

The new colleague can deploy as soon as the project's grim.json names the host under deploy. Their own servers.json may be empty. Have them try a read-only command first.

$ grim env:pull

Questions

Can it manage another account than deploy?

Yes, with --user. It works on /home/<user>/.ssh/authorized_keys of any account whose home is there. For the shared dev user of a dev box there is grim server:dev:keys, the same command with dev as the default.

Does removing a key end a session that is already open?

No. The file is read when a connection is made. A colleague who is logged in stays in until that session closes.

Related spells