User Management
Users are the unit of identity on Linux: every process runs as one, and every file belongs to one. Learn the account files (/etc/passwd and /etc/shadow), create accounts with useradd and adduser, set and rotate passwords, modify and remove accounts with usermod and userdel, and master privilege escalation with sudo — including editing /etc/sudoers safely via visudo.
What is this?
A user is the fundamental unit of identity in Linux: every process runs as some user, every file belongs to some user, and the kernel enforces boundaries between users automatically. User management is the craft of creating, changing and removing those identities — via useradd or adduser for creation, passwd for passwords, usermod for edits, userdel for removal, and sudo for controlled privilege escalation. Get it right and a compromise of one account stays contained; get it wrong and you are one shared root password away from losing the whole machine.
Why do you need it?
- Containment: a process running as www-data that gets exploited can only touch www-data's files, not the database or the kernel.
- Auditing: logs record uids, so 'who did what and when' is answerable for every command executed with sudo.
- Isolation on shared servers: individual logins give each person their own home and permissions without sharing passwords.
- Least privilege: sudo grants specific commands to specific users instead of the all-or-nothing root login.
- Offboarding: a leaver's access is revoked by deleting one account, not by changing a shared password everyone knows.
Mental model
A hotel with guest keycards and one master key locked in the safe
Linux users and sudo
Each guest (user) gets a keycard that opens their own room (home directory) and shared floors (groups). The master key (root) never leaves the safe. Instead of copying it, staff are issued a sudo badge that opens specific doors and logs every time it is used — so you always know who entered what.
How it works
- /etc/passwd stores one line per user: name, an x placeholder for the password, uid, gid, a comment field, home directory and login shell. It is world-readable because programs need the metadata — never the hash.
- /etc/shadow stores the actual password hash plus ageing policy (last change, minimum/maximum age, warning, inactivity) and is readable only by root, so hashes never leak to normal users.
- useradd registers a new account — writing to /etc/passwd and /etc/shadow and, with -m, creating the home directory — while passwd sets or rotates the password by updating the hash in /etc/shadow.
- usermod edits an existing account in place: locking/unlocking, adding groups with -aG, changing the shell or home, or expiring the account — all without deleting and recreating it.
- userdel removes the account; with -r it also removes the home directory and mail spool. Escalation to run any of this is granted through /etc/sudoers, edited safely with visudo, which syntax-checks the file before saving.
What happens when a user logs in and authenticates.
Key commands
id aliceShow alice's numeric uid, primary gid and every group membership in one line.
uid=1001(alice) gid=1001(alice) groups=1001(alice),27(sudo)
grep alice /etc/passwdShow alice's account line: name, x, uid, gid, comment, home, shell.
alice:x:1001:1001:Alice Smith:/home/alice:/bin/bash
sudo tail -1 /etc/shadowRoot-only view of alice's password hash and ageing policy.
alice:$6$KfQ9mZs2$2gHv...hash...abridged:19000:0:99999:7:::
sudo useradd -m -s /bin/bash -c 'Dev One' dev1Create dev1 with a home directory, bash login shell and a comment.
No output on success — verify with id dev1 or ls /home.
sudo passwd aliceSet or rotate alice's password; the hash lands in /etc/shadow.
New password: Retype new password: passwd: password updated successfully
sudo usermod -aG sudo aliceAppend alice to the sudo group without touching her other groups.
No output on success — the change applies at her next login.
sudo userdel -r aliceDelete the account, its home directory and its mail spool.
No output on success — the account is gone from /etc/passwd and /etc/shadow.
sudo -l -U alicePrint every sudo rule that applies to alice — your audit trail in one command.
User alice may run the following commands on host:
(ALL : ALL) ALLExamples
Provision a developer account with sudo
# 1. Create the account with a home directory and bash shellsudo useradd -m -s /bin/bash -c "Alice Smith" alice # 2. Set an initial passwordsudo passwd alice # 3. Grant admin rights via the sudo group (Debian/Ubuntu)sudo usermod -aG sudo alice # 4. Verify the account and its privilegesid alicesudo -l -U aliceuseradd -m creates the home directory and -s sets the login shell. passwd prompts for the initial password, hashing it into /etc/shadow. usermod -aG sudo adds alice to the sudo group, whose membership rule (%sudo ALL=(ALL:ALL) ALL) lives in /etc/sudoers. sudo -l -U alice lists exactly what alice may run — the audit trail starts here.
In production
- Service accounts: nginx runs as www-data, databases as their own user, apt as _apt — a breach inside one service cannot read another service's files.
- Sudo is the gate to production: teams get scoped sudoers entries (a restart-only rule for operators, NOPASSWD for CI) and every escalated command is logged.
- SSH keys plus named accounts replace shared passwords entirely, and userdel -r deprovisions a leaver in seconds.
- Identity is the unit of compliance: RBAC, PAM modules and audit tooling all key off users and their group memberships.
Best practices
- Never do daily work as root — create a personal account and escalate with sudo for everything.
- Give every human and every service its own account; shared logins destroy audit trails.
- Edit sudoers only through visudo (or visudo -f /etc/sudoers.d/<file>), never with a raw editor.
- Lock accounts that no longer need access (usermod -L) and remove them with userdel -r once confirmed.
- Use NOPASSWD sparingly and only for a precise command list, e.g. systemctl restart my-app.
- Keep /etc/shadow at 640 root:shadow and enforce strong password hashing and ageing policy.
Common mistakes
- Deleting accounts that still own files: userdel leaves those files orphaned under a numeric uid, which a future account could reclaim.
- Sharing one account or the root password 'for convenience' — nobody can be held accountable afterwards.
- Using adduser and useradd interchangeably without knowing their defaults differ between distros (home, shell, sudo group).
- Dropping the -a in -aG: usermod -G sudo alice replaces every secondary group, silently stripping existing privileges.
- Leaving default password ageing: accounts with 99999 max days in /etc/shadow never expire unless you set a policy.
Common issues
useradd: user 'alice' already existsAn account with that name (or a leftover /etc/passwd entry) already exists.
Inspect with id alice and getent passwd alice, then reuse the account or clean it up before creating a new one.
su: Authentication failureThe user has no password set (created with --disabled-password) or you mistyped it.
Set a password with sudo passwd alice, or unlock a locked account with usermod -U / passwd -u first.
alice is not in the sudoers file. This incident will be reported.The account exists but has no sudo entitlement on this distro — not in the sudo/wheel group and no sudoers.d entry.
Run sudo usermod -aG sudo alice (Debian/Ubuntu) or sudo usermod -aG wheel alice (RHEL), then have alice log out and back in.
Debugging tips
- id <user> and groups <user> show memberships; compare them when access is refused — a stale login is the usual culprit.
- getent passwd alice queries the real name service (files, LDAP, sssd) — more truthful than cat /etc/passwd on enterprise boxes.
- grep alice /etc/passwd /etc/shadow /etc/group reveals exactly which files know about the account.
- chage -l alice shows expiry state — an account can exist yet be locked or expired.
- sudo -l -U alice lists every rule alice can use; print it before assuming sudo works.
Interview checkpoint
Hands-on lab
- Create accounts with useradd and inspect them in /etc/passwd
- Set and rotate passwords with passwd
- Grant and scope sudo access with usermod -aG and visudo
- Lock and unlock accounts with usermod -L / -U
- Remove accounts cleanly with userdel -r
Create, manage and remove user accounts safely
13 min · beginner
Quick quiz
Which file stores the actual password hashes?
What is special about uid 0?
sudo usermod -G sudo alice adds alice to the sudo group without affecting her other groups.
Which command creates a login-capable user with a home directory and bash on Ubuntu?
A new teammate must be able to restart and check the status of nginx — but nothing else on production. What is the safest setup?
What does the x in the second field of /etc/passwd entries mean?
Cheat sheet
id <user>uid, primary gid and all group membershipswhoamicurrent effective usergetent passwd <user>account line from the real name service (files/LDAP)chage -l <user>password and account expiry policygroups <user>secondary groups onlyuseradd -m -s /bin/bash alicecreate with home and bash shelladduser aliceDebian-friendly interactive wizardpasswd aliceset or rotate the passwordusermod -aG sudo aliceappend to sudo (never forget -a)usermod -L alice / -U alicelock / unlock the accountusermod -s /sbin/nologin alicedisable login for service accountsusermod -e 2026-12-31 aliceexpire the account on a dateuserdel alicedelete the account onlyuserdel -r alicealso delete home and mail spoolfind / -uid 1001find files owned by a uid before deletingvisudoedit /etc/sudoers safely (syntax check on save)visudo -f /etc/sudoers.d/aliceedit a per-user drop-in filesudo -l -U alicelist every rule alice may use%sudo ALL=(ALL:ALL) ALLDebian/Ubuntu sudo-group rulealice ALL=(ALL:ALL) NOPASSWD: /usr/bin/systemctlpasswordless, scoped to one command/etc/passwdmetadata: name, uid, gid, home, shell — world-readable/etc/shadowhashes + ageing — root-only (640 root:shadow)/etc/sudoersescalation policy — edit only via visudo/etc/sudoers.d/drop-in rules, included by the main file