User Management Commands

Linux user management is one of the core responsibilities of system administrators. Command-line tools make it possible to create accounts, adjust permissions, update group memberships, and remove obsolete users consistently across servers, containers, and automated environments.

A useful mental model is that Linux stores identities and access relationships separately:

• /etc/passwd contains basic user information.
• /etc/shadow stores protected password data.
• /etc/group defines groups and their members.
• PAM and the Name Service Switch (NSS) can integrate local accounts with centralized authentication and directory services.
  The useradd command is the standard low-level utility for creating local users. Its defaults vary between distributions, so important options should always be specified explicitly.

sudo useradd -m -s /bin/bash alice
sudo passwd alice

In this example:

• -m creates the user’s home directory and copies the standard skeleton files from /etc/skel.
• -s sets the login shell, here to Bash.
• passwd alice sets the password interactively without exposing it in shell history or process listings.

Additional options can define the account’s full name, UID, primary group, and supplementary groups:

sudo useradd \
  -m \
  -s /bin/bash \
  -c "Alice Morgan" \
  -u 1501 \
  alice

Before assigning a UID, check whether it is already in use:

getent passwd 1501

adduser is available on many Debian- and Ubuntu-based systems as a higher-level, interactive interface to useradd. It usually asks for account details and offers sensible defaults, making it convenient for manual administration. On other distributions, adduser may be an independent tool with different options, so its manual page should be reviewed before use.

For service accounts that should not support interactive login, use a non-login shell:

sudo useradd -r -s /usr/sbin/nologin appservice

Updating Existing Accounts

The usermod utility changes attributes of an existing account. Common tasks include changing the login shell, moving a home directory, and modifying group membership.

sudo usermod -s /bin/zsh alice

To change a home directory, specify the new location and request that the existing files be moved:

sudo usermod -m -d /srv/home/alice alice

Supplementary groups are often used to grant access to resources such as shared repositories, Docker sockets, or deployment tools:

sudo usermod -aG docker alice

The -a option is essential. It means append. Without it, usermod -G replaces the user’s entire list of supplementary groups:

sudo usermod -aG developers,deployers alice

A user normally must start a new login session before newly assigned supplementary groups become active.

The primary group can also be changed, although administrators should consider the ownership of existing files first:

sudo usermod -g engineering alice

Changing a UID with usermod -u does not automatically transfer ownership of every file owned by that user. Files outside the home directory may require manual inspection with commands such as find.

Passwords and Account Locking

Use passwd to set or change a password interactively:

sudo passwd alice

The command prompts for the new password and its confirmation, which is safer than passing credentials directly on the command line. Administrators should also review password-age and account-expiration policies with chage.

For an account that is temporarily inactive, locking the password is usually preferable to deleting it:

sudo usermod -L alice

The account remains visible and can be restored later:

sudo usermod -U alice

If the account should be disabled completely, its shell can be changed to /usr/sbin/nologin or /bin/false. A password lock and a shell restriction address different risks, so organizations may choose to apply both.

Managing Groups

Groups provide a practical way to administer shared permissions. Create a group with groupadd:

sudo groupadd developers

Add or remove members with gpasswd:

sudo gpasswd -a alice developers
sudo gpasswd -d alice developers

A user can belong to multiple groups, but each account has only one primary group. The primary group is specified with usermod -g, while additional groups are managed with -aG.

Existing groups can be renamed or given a new GID:

sudo groupmod -n application-developers developers
sudo groupmod -g 2500 developers

Before changing a GID, verify that no unrelated group already uses the replacement value.

Verifying Identity and Membership

After making changes, verify the effective account configuration rather than assuming the command succeeded.

The id command displays the UID, primary GID, and group memberships:

id alice

A typical result might look like this:

uid=1501(alice) gid=1501(alice) groups=1501(alice),27(sudo),998(docker)

Use getent to query account databases through the system’s configured naming services:

getent passwd alice
getent group developers

getent is especially useful in environments that combine local files with LDAP, Active Directory, or another directory service. Searching /etc/passwd directly may miss accounts provided by those external systems.

The following commands provide additional operational context:

ls -ld /home/alice
who
w
lastlog
last

They help confirm directory ownership, identify active sessions, and review recent login activity.

Removing Users Safely

The userdel command removes a local account:

sudo userdel bob

Add -r to remove the user’s home directory and mail spool as well:

sudo userdel -r bob

The -r option does not delete files stored elsewhere, including application data, backups, or files in shared directories. Before deleting an account, administrators should:

1. Confirm that the account is no longer needed.
2. Back up any important personal or operational data.
3. Check for running processes with who, w, or ps -u bob.
4. Terminate active services or sessions owned by the user.
5. Verify the home-directory path to avoid removing the wrong data.

The userdel -f option can force removal even when conflicts exist, but it should be treated as a last resort. Forced deletion may leave orphaned files and services behind.

Security and Operational Practices

Effective user administration starts with least privilege. Give users only the groups and commands they require instead of granting direct root access. When elevated privileges are necessary, edit the sudoers configuration with visudo rather than modifying it with an unrestricted text editor:

sudo visudo

Regular audits help identify dormant or unexpected accounts. Review login history, current sessions, UID assignments, and group memberships. Accounts that are no longer required should be removed according to the organization’s retention policy; temporarily inactive accounts should generally be locked.

Authentication policy should be enforced centrally through PAM where possible. PAM can support password-quality requirements, failed-login lockouts, two-factor authentication, and session controls. Combining a strong authentication policy with SSH keys, short-lived credentials, and centralized logging provides a stronger defense than relying on complex passwords alone.

In automated deployments, every account-creation step should be validated. Check whether the account already exists, choose UIDs and GIDs deliberately, and confirm that home-directory permissions match the intended security model. Repeatable administration scripts should also handle existing accounts gracefully rather than failing partway through provisioning.

Finally, every destructive action should include a verification step. Commands that alter identities, permissions, or file ownership can affect applications and active sessions even when they appear successful. A short review after each change is an essential part of reliable Linux administration.