SSH Key Rotation for a Small Team: Inventory, Replace, Verify, Revoke

SSH key rotation is manageable when you know which key belongs to each person and automation job. A shared private key copied among colleagues makes revocation ambiguous: removing it can break everyone, while leaving it in place preserves access for a departed user. Establish individual ownership before treating rotation as a calendar task. Keep human administration and unattended deployment credentials separate.

Build an access inventory

Record each authorized public-key fingerprint, account, owner, purpose, and server scope. Include deployment pipelines, backup jobs, and emergency access. Key comments can help identify intent, but they are editable labels rather than proof of ownership. Confirm the relationship with the responsible person or system owner.

Check whether keys are supplied directly through an authorized-keys file or through another approved mechanism. Configuration management may restore a key that you remove manually. The rotation plan must update the source of truth as well as the current server, otherwise the next deployment can quietly undo the revocation.

Replace with a verified overlap

Generate and protect the replacement credential according to your organization's policy and the installed OpenSSH capabilities. Keep private material on the authorized client or secret storage. Add only the public key to the intended account. Preserve a working administration session and verify that the recovery console is available before changing access.

Test a fresh connection that explicitly uses the replacement identity, then perform an authorized harmless action under the expected account. Connection reuse can make a test appear successful without exercising the new key, so ensure the verification establishes a new authentication. Record which fingerprint was tested and on which server.

Revoke the precise old authorization

After the replacement succeeds, remove the old key from each approved location in scope. Verify that a new authentication attempt with the old credential fails while the replacement still works. Do not remove unrelated keys or rewrite an entire access file from memory. Maintain the intended ownership and permissions when using the distribution's normal tools.

For an employee departure, also review non-SSH access and active sessions according to your offboarding process. Deleting a public key prevents future authentication through that authorization; it does not necessarily terminate an already established session or remove credentials the person copied elsewhere. Treat suspected compromise as an incident with an appropriately broader investigation.

Exercise automation before closing the change

Run the deployment or backup job through its documented verification path after rotation. Check that secrets did not enter logs and that host-key verification remains active. Keep the inventory current and retire unused credentials. The final record should show who can still connect, which old access was removed, and what was actually tested, rather than simply saying that keys were updated.

Refer to the OpenSSH key utility documentation for supported key operations. Our Vaultwarden hosting guide discusses another credential-sensitive workload, and LayerOne docs cover the server management context.