To revoke SSH access when an employee or contractor leaves, disable access at its source, remove or revoke their keys, review administrator privileges, and test that the former credentials no longer work. Treat this as a coordinated offboarding task across identity systems and servers, not as a single account deletion.
A password lock alone may not stop public-key authentication. Similarly, removing ~/.ssh/authorized_keys may miss keys supplied by a central service or a different SSH configuration. Use this checklist to contain access promptly, complete cleanup without losing needed records, and document the result.
1. Identify where access is controlled
Start with the systems that can grant login access. Check the organization’s identity provider or directory, SSH certificate or key management, VPN, bastion hosts, cloud accounts, and any configuration management or access automation. Disable the person’s access in centrally managed systems first, following your organization’s process. A local Linux change cannot revoke access still granted through an external provider.
Make an inventory of the hosts and environments the person could reach, including production, staging, development, and systems managed by a vendor or cloud provider. Check whether they used a shared or service account. If so, identify who else depends on it before changing credentials, and plan a replacement credential for legitimate ongoing use.
For a broader transition process, see this Linux administrator handover checklist.
2. Disable the account and preserve what is needed
Disable the person’s identity through the authoritative account system, then apply the corresponding change to local Linux accounts where required. Ubuntu’s user management documentation describes common account administration tasks; exact commands and behavior can vary across distributions and authentication setups.
Before deleting an account, determine whether its home directory, files, scheduled jobs, application ownership, or audit records must be retained or transferred. Preserve required data according to your organization’s retention and access procedures. You can disable an account promptly and remove it later, after owners confirm that its data and dependencies have been handled.
Do not assume that locking the password alone blocks SSH key login. Its effect depends on the system’s SSH and account-authentication configuration. Treat the account as disabled only after applying the appropriate control and testing it on representative hosts.
3. Find and revoke every SSH key source
Check the departing user’s home directory for ~/.ssh/authorized_keys, but do not stop there. Review the effective SSH server configuration for AuthorizedKeysFile and AuthorizedKeysCommand. These settings can point to alternate key files or a command that retrieves keys from an external source. The sshd_config manual explains these options.
Also inspect central identity tools, SSH certificate authorities, cloud access mechanisms, bastion or jump-host configuration, and configuration management repositories. Remove the user’s key or disable its authorization at the system that supplies it. If a key is shared, rotate it and update every approved dependency rather than simply deleting it and disrupting other users.
When access is managed through certificates or a centralized key service, revoke the person’s authorization there as well as checking individual hosts. Record which sources you checked so the review is repeatable and gaps are visible.
4. Remove sudo and other administrator privileges
Review both direct and inherited privileges. Check the user’s group membership, including groups used for administrative access, and inspect sudo policy files such as /etc/sudoers and files included from /etc/sudoers.d. Also check role-based access in identity tools, configuration management, and cloud platforms.
Remove grants through the system that owns them. If you edit sudo policy, use the approved validation process, such as visudo, before applying changes. Confirm that no group membership or included rule continues to grant administrative rights. Consider access to tools that can elevate privileges or control systems, not just direct sudo entries.
5. End active sessions and review credentials
Revoking a key or disabling an account does not necessarily close an SSH session that is already connected. Identify the person’s active sessions and processes, coordinate with the relevant system owner, and terminate them using the system’s normal session-management procedure. On systems that use systemd-logind, an administrator may use loginctl terminate-user username after confirming the effect on that user’s running work. Avoid ending processes blindly if they could affect a service or business operation.
Review other credentials the person could access or have used: API tokens, deployment keys, automation secrets, database credentials, and shared passwords. Rotate credentials that are shared or cannot be reliably attributed to one person, and update dependent services through a controlled change process.
6. Verify that the old access no longer works
Make verification an explicit sign-off, not an assumption. From an approved test location, attempt to connect to representative hosts using the former account and key. Confirm that login is denied. Where access was centrally managed, verify the change at that control point too. Test both ordinary SSH access and any administrator route that was available.
Check that the account cannot obtain sudo privileges, that active sessions have ended, and that no alternate key source still authorizes the old credential. Review authentication or access logs for the relevant attempts and record the systems tested, changes made, exceptions, and result. Do not use a real person’s private key for testing unless your security process explicitly allows it; a controlled test using the credential’s authorized verification method is preferable.
SSH offboarding checklist
- Disable the person in the central identity, SSH key, certificate, VPN, bastion, and cloud systems that grant access.
- Inventory reachable hosts and identify shared accounts, service dependencies, and data that must be preserved.
- Disable applicable Linux accounts; do not rely on a password lock alone as proof that SSH is blocked.
- Find keys in authorized_keys, configured alternate files, command-backed sources, and central access systems.
- Remove sudo grants, administrator group memberships, and related role assignments.
- Terminate existing sessions through an appropriate, coordinated process.
- Review and rotate shared or otherwise exposed credentials, updating dependent services.
- Test the former account and credential against representative systems, then document the outcome.
Frequently asked questions
Does locking a Linux account stop SSH key authentication?
Not reliably in every setup. Password locking and SSH public-key authentication are different controls, and behavior depends on SSH, PAM, and account configuration. Disable access using the authoritative identity controls, address the key sources, and verify that login is denied.
Where should I look for a user’s authorized SSH keys?
Start with the user’s ~/.ssh/authorized_keys, then check the effective AuthorizedKeysFile setting, any AuthorizedKeysCommand, and external identity or key-management systems. Centralized access may mean there is no local key file to edit.
Should I disable or delete the Linux account first?
Disable access promptly, then preserve or transfer needed files, records, and dependencies before deleting the account. Deletion is cleanup, not a substitute for revoking keys and centrally managed access.
How do I terminate existing SSH sessions?
Find active sessions and coordinate with the system owner before ending them, especially if user processes may support business work. Use the host’s normal session-management method and confirm the sessions have ended.
Make offboarding verifiable
A reliable SSH offboarding process covers identity systems, Linux accounts, every key source, administrator rights, active sessions, and credentials beyond SSH. The key safeguard is verification: test the former access path and record what was checked. Linux Consulting Services provides 24/7 Linux consulting, monitoring, and technical support. For help reviewing Linux access controls, contact the team at (904) 658-0777.