Rotate and revoke keys

Start from the behavior you can observe. A new operator key is installed and tested before the old fingerprint is removed from every server.

SSH keys do not expire automatically in ordinary authorized_keys setups, so ownership and rotation need an operational process. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

It is tempting to remove the only working key first or leave departed users authorized indefinitely. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to maintain an owner-and-purpose inventory, add and verify the replacement, revoke the old key, and audit all targets. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Operate SSH access over time with narrow automation, regular rotation, revocation, and rehearsed recovery. Record enough evidence that another developer can repeat the result without relying on your memory.

Rotate one test identity across two servers and prove the old key is rejected everywhere. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.