All six administrators of a Linux server fleet in the cloud use the same SSH private key, which is kept on a shared file server. One administrator has just left the company. What is the best long-term fix?
Select an answer to reveal the explanation.
Short Explanation
A shared SSH key is one house key cut six times: you can't tell who opened the door, and you can't take back one copy. Give everyone their own key, or better, a short-lived certificate that just expires. Rotating the shared key is a treadmill, not a fix.
Full Explanation
SSH access should be tied to individual identities. With a separate key pair per administrator, the public key on each server identifies who connected, logs attribute actions to a person, and removing one person's key revokes only that person. Short-lived SSH certificates go further: a certificate authority signs a user's key for a limited period after the user authenticates to the identity provider, servers trust the CA rather than individual keys, and access ends automatically when the certificate expires or the identity is disabled. Rotating the shared key after each departure is a recurring emergency that disrupts every administrator, still provides no individual accountability, and keeps the key on a file server where many people can copy it. Adding a passphrase protects the key file at rest, but the departing administrator already knows the passphrase, and shared credentials remain unattributable. Restricting SSH to the corporate IP range reduces exposure but is not identity control, and staff still share one credential. Exam caveat: the outline groups SSH with other remote access mechanisms; questions favour accountability and centralized revocation over network tricks. Operational check: confirm that each server's authorized keys or trusted CA configuration contains no shared key, that SSH logs show individual principals, and that disabling a test identity prevents new certificates from being issued.