Revoking an old SSH key after a developer leaves

Identify the key by its fingerprint and owner rather than its filename alone. Keep a verified alternative administrator access method available so you do not lock out the only authorised maintainer.

1. Open SSH Access > Manage SSH Keys and locate the public key associated with the retired device or person.
2. Use Manage and choose Deauthorize. Verify its authorization status changes.
3. Remove the obsolete stored key entry when it is no longer needed, distinguishing public and private-key records where both exist.
4. Test a fresh connection using the retired key if you control it. Review active sessions with support when immediate termination is required.
5. Revoke separate FTP users, cPanel team identities, API tokens and application accounts associated with the same person. Rotate shared credentials they knew when the handover requires it.

The old key should fail on a new authentication attempt, while the retained authorised maintainer can still connect. Record the revoked fingerprint and completion time.

If access continues, verify the client did not fall back to another key or password. A key can also be authorised under a separate account or duplicated in an authorized-keys file, which requires review.

No. Other copies of the private key can still authenticate while the public key remains authorised. Revoke authorization on every relevant server and repository where the exposed key was trusted.

• Adding an SSH public key to a cPanel account
• Revoking a departing team member’s cPanel access
• Creating a cPanel API token for an authorised integration
• Cloning a private Git repository through cPanel

• cPanel: SSH Access