Introduction

Secure account management limits who can sign in, what they can administer, and how access is reviewed. Apply the Principle of Least Privilege: give each person or service only the permissions required for its defined task, then audit those permissions regularly.

Prerequisites

  • An approved administrator account with sudo access, plus a tested backup or console recovery path.
  • The target username, required groups, business owner, and approved access duration.
  • A separate active administrator session before changing SSH or sudo configuration.

01 — Create and review users

Create named accounts for individual administrators instead of sharing credentials. Review identity and group membership after each change.

Terminal
sudo adduser newuser
sudo usermod -aG sudo newuser
id newuser

On Ubuntu, membership in the sudo group grants broad administrative capability. Add it only when the account genuinely needs administration, and remove it when the role ends.

02 — Account lifecycle

Locking an account blocks password-based login for that account but is not a complete access-removal procedure on every system. Review SSH keys, running sessions, scheduled jobs, group membership, and service credentials as part of offboarding.

Terminal
sudo passwd -l username
sudo passwd -u username
sudo chage -l username

03 — sudo and controlled privilege

Use sudo for specific approved commands instead of long-lived root sessions. Review the effective policy with sudo -l. Edit sudoers only through visudo because it validates syntax and helps prevent a broken sudo configuration from locking administrators out.

Terminal
sudo -l
sudo visudo

Do not edit sudoers with a regular text editor. Test an additional administrator account and retain a console recovery path before changing sudo policy.

04 — SSH keys and SSH hardening

Use unique SSH key pairs per administrator, protect private keys with a passphrase, and remove public keys when access is no longer required. OpenSSH reads user public keys from authorized-key files; protect account home and .ssh permissions so untrusted users cannot modify authorized keys.

After verifying key-based login in a second session, harden root access in the SSH server configuration and validate the configuration before reloading the service.

OpenSSH configuration
PermitRootLogin no
PubkeyAuthentication yes
Validate and reload
sudo sshd -t
sudo systemctl reload ssh

Do not disable password authentication or root login until a separate key-based administrator session has been tested. Keep the original session open while validating the change.

05 — Permissions and audit

Use owner, group, and mode permissions to protect files and directories. Service accounts should be non-interactive where practical and must not receive sudo without a documented requirement. Audit local accounts, group membership, sudo policy, SSH authorized keys, authentication logs, and privileged actions on a regular schedule.

06 — Test the access model

  1. Log in with the new account and run id newuser to confirm intended groups.
  2. Run sudo -l as that account and verify that the displayed privileges match the approved role.
  3. Test SSH key login in a separate session; after SSH hardening, confirm root login is denied and the approved administrator access still works.

Troubleshooting

  • New user cannot use sudo: check id, the intended group or sudoers policy, and the output of sudo -l.
  • SSH key is rejected: verify the correct username, public-key contents, authorized_keys location, account home/.ssh permissions, and sshd logs.
  • Access was removed but a session remains: terminate or review active sessions according to the organization’s approved incident and offboarding process.

Best Practices

  • Use named accounts, MFA where available, unique SSH keys, and time-bound privileged access.
  • Keep an emergency administrator process that is documented, protected, audited, and regularly tested.
  • Review and remove dormant accounts, unused group memberships, stale SSH keys, and unnecessary sudo permissions.

Frequently Asked Questions

Should sudoers be edited with a text editor?

No. Use sudo visudo so syntax is validated before the change is saved.

Does locking a password remove all access?

No. Review SSH keys, active sessions, group membership, scheduled jobs, and service credentials as part of offboarding.

Conclusion

Secure Linux access management combines named accounts, minimal group and sudo rights, protected SSH keys, disabled root SSH login where appropriate, and regular audit. Make every access change reversible, documented, and tested from a separate administrative session.

Official references

Share