Linux User and Group Management Commands: The Complete 2027 Guide

Every Linux server you manage starts with the same question: who is allowed to do what? User and group management is the foundation of access control, auditing and least privilege.

This guide covers the commands you need to create, modify, lock and delete accounts, manage groups, control password aging, grant administrative rights safely and audit who is logged in. Each section includes working examples, the files involved, the differences between Ubuntu or Debian and RHEL-family systems, and the mistakes that most often cause outages or security gaps. Use it as a tutorial the first time and as a reference after that.

Core concepts and the files behind them

Linux identifies every account by a numeric UID and every group by a numeric GID. Names are labels for those numbers. Each user has one primary group (recorded in /etc/passwd) and any number of supplementary groups (recorded in /etc/group).

The key files

Anatomy of an /etc/passwd line

From left to right: login name, password placeholder (the real hash lives in /etc/shadow), UID, primary GID, comment (GECOS) field, home directory and login shell.

Inspect users and groups

Start by learning to read the current state. These commands are safe and non-destructive.

# Who am I, and what is my identity?
whoami
id

# Identity of a specific user (UID, primary GID, all groups)
id alice

# Groups a user belongs to
groups alice

# Look up an account or group through all name sources (local files, LDAP, SSSD)
getent passwd alice
getent group devs

# List every regular user (UID 1000 to 65533)
getent passwd | awk -F: '$3 >= 1000 && $3 < 65534 {print $1, $3, $6, $7}'

# List members of a group
getent group sudo

Create users: useradd and adduser

useradd: the portable, scriptable tool

useradd exists on every distribution. By default it may not create a home directory unless you pass -m (or CREATE_HOME yes is set in /etc/login.defs), so be explicit.

# A normal user with home, shell, comment and supplementary groups
sudo useradd -m -s /bin/bash -c "Alice Smith" -G devs,docker alice

# Set the initial password (prompts twice)
sudo passwd alice

# Force a password change at first login
sudo chage -d 0 alice

# A system account for a service: no login shell, no home directory
sudo useradd -r -s /usr/sbin/nologin -c "App service account" appsvc

# A user with an account expiry date (contractor)
sudo useradd -m -e 2027-03-31 -c "Contractor" vendor1

# Show the defaults used by useradd
useradd -D

adduser: the friendly Debian and Ubuntu wrapper

On Debian and Ubuntu, adduser is a Perl script that asks for a password and personal details, creates the home directory by default and follows distribution policy. On Red Hat-family systems, adduser is simply another name for useradd.

# Debian / Ubuntu: interactive
sudo adduser alice

# Add an existing user to an existing group (Debian family)
sudo adduser alice devs

# System user without a login (Debian family)
sudo adduser --system --group --no-create-home appsvc

Modify users: usermod

usermod changes an existing account. The most dangerous mistake in this whole guide lives here.

# Append a supplementary group (safe)
sudo usermod -aG docker alice

# Replace the whole supplementary group list (careful)
sudo usermod -G devs,docker alice

# Change the login shell (or let users run chsh themselves)
sudo usermod -s /bin/zsh alice

# Change the primary group
sudo usermod -g devs alice

# Rename the login (home directory and group are NOT renamed automatically)
sudo usermod -l alicia alice

# Rename the login, move the home directory and rename the primary group
sudo usermod -l alicia -d /home/alicia -m alice
sudo groupmod -n alicia alice

# Set or remove an account expiry date
sudo usermod -e 2027-06-30 alice
sudo usermod -e "" alice

# Lock and unlock the password
sudo usermod -L alice
sudo usermod -U alice

Delete users: userdel

# Remove the account only (home directory and files remain)
sudo userdel alice

# Remove the account, home directory and mail spool
sudo userdel -r alice

# Debian family alternative
sudo deluser --remove-home alice

# Remove the user and back up the home directory first
sudo tar czf /backup/alice-home-$(date +%F).tgz /home/alice
sudo userdel -r alice

Before you delete

1. Check for running processes with ps -u alice and stop or reassign them. userdel will refuse if the user is logged in.
2. Back up the home directory if the data might be needed for compliance, handover or investigation.
3. Check cron jobs, services and mail owned by the user: sudo crontab -l -u alice.
4. Delete the account with userdel -r.
5. Find orphaned files that still carry the old UID and reassign or remove them.

# Find files that no longer belong to any user or group
sudo find / -xdev \( -nouser -o -nogroup \) -ls 2>/dev/null

# Reassign files from an old UID to a new owner
sudo find /srv -xdev -uid 1001 -exec chown newowner {} +

Passwords, aging and locking

passwd

# Change your own password
passwd

# Set another user's password (root)
sudo passwd alice

# Show password status (L = locked, P = usable, NP = no password)
sudo passwd -S alice

# Lock and unlock the password
sudo passwd -l alice
sudo passwd -u alice

# Expire the password now, forcing a change at next login
sudo passwd -e alice

chage: password aging and account expiry

# Show aging information
sudo chage -l alice

# Require a change every 90 days, minimum 1 day between changes, warn 7 days before
sudo chage -M 90 -m 1 -W 7 alice

# Disable the account 14 days after the password expires
sudo chage -I 14 alice

# Set an absolute account expiry date
sudo chage -E 2027-03-31 alice

# Force a password change at next login
sudo chage -d 0 alice

Which lock should you use?

There are several ways to stop an account from working, and they are not equivalent.

# A thorough "offboard now" sequence
sudo usermod -L -e 1 -s /usr/sbin/nologin alice
sudo pkill -KILL -u alice          # end running sessions and processes
sudo mv /home/alice/.ssh/authorized_keys /home/alice/.ssh/authorized_keys.disabled

Manage groups

# Create a group (optionally with a fixed GID)
sudo groupadd devs
sudo groupadd -g 2000 finance

# Create a system group
sudo groupadd -r appsvc

# Rename or renumber a group
sudo groupmod -n engineers devs
sudo groupmod -g 2100 engineers

# Delete a group (it cannot be the primary group of any user)
sudo groupdel engineers

# Add and remove members with gpasswd
sudo gpasswd -a alice devs
sudo gpasswd -d alice devs

# Set the exact member list
sudo gpasswd -M alice,bob,carol devs

# Delegate: make bob a group administrator who can manage members
sudo gpasswd -A bob devs

# Start a subshell with a different primary group
newgrp devs

A practical example: a shared project directory

Groups work best combined with directory permissions. The setgid bit makes new files inherit the directory’s group, so everyone on the team can collaborate.

sudo groupadd projectx
sudo mkdir -p /srv/projectx
sudo chown root:projectx /srv/projectx
sudo chmod 2770 /srv/projectx          # setgid + rwx for owner and group, nothing for others
sudo usermod -aG projectx alice
sudo usermod -aG projectx bob
ls -ld /srv/projectx                    # drwxrws--- root projectx

sudo, wheel and privilege escalation

Granting admin rights

The administrative group differs by distribution family:

Editing sudoers safely

Always edit sudoers with visudo, which checks syntax before saving. A broken sudoers file can lock you out of all administrative access.

# Edit the main file safely
sudo visudo

# Preferred: a drop-in file per purpose (keeps changes isolated and auditable)
sudo visudo -f /etc/sudoers.d/90-deploy

# Validate all sudoers files
sudo visudo -c

# /etc/sudoers.d/90-deploy
# Allow the "deploy" user to restart one service without a password
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp.service

# Allow the "devs" group to run package updates only
%devs ALL=(root) /usr/bin/apt update, /usr/bin/apt upgrade

# Check the files have safe permissions
ls -l /etc/sudoers.d/            # should be -r--r----- (0440), owned by root

# See what a user may run
sudo -l -U alice

What changed in 2027: sudo-rs and run0

• sudo-rs on Ubuntu. Ubuntu 25.10 and the 26.04 LTS ship sudo-rs, a memory-safe Rust reimplementation, as the default sudo. It is designed as a near drop-in replacement, but it deliberately implements a subset of sudoers features, so some advanced directives are not supported. Reports indicate Canonical plans to drop the original sudo fallback in Ubuntu 26.10, so validate your rules now.
• Debian packages sudo-rs but, at the time of writing, does not make it the default.
• run0. systemd 256 and newer include run0, which elevates privileges without a setuid binary. It works on current Fedora, Arch and Ubuntu releases that carry a recent systemd.

# Which sudo do I have?
sudo --version
update-alternatives --list sudo 2>/dev/null     # Ubuntu: shows both implementations if installed

# Validate every sudoers file after an upgrade or migration
sudo visudo -c

# systemd's alternative (systemd 256+)
run0 systemctl restart nginx

su and the root account

su - alice                    # become alice with her environment (needs her password, or root)
sudo -i                       # root login shell via sudo
sudo -u appsvc whoami         # run one command as another user

# Many servers lock the root password and require sudo
sudo passwd -l root
grep -i PermitRootLogin /etc/ssh/sshd_config

Failed logins and faillock

Repeated failed logins can lock an account. On current Red Hat-family systems, and many modern distributions, this is handled by pam_faillock. The older pam_tally2 module has been removed from current distributions. If a tutorial tells you to run pam_tally2 and the command is missing, use faillock.

# Show failed login records for a user
sudo faillock --user alice

# Unlock the user by clearing the failures
sudo faillock --user alice --reset

# Show records for all users
sudo faillock

# /etc/security/faillock.conf  (typical settings)
deny = 5               # lock after 5 failed attempts
unlock_time = 900      # unlock automatically after 15 minutes
fail_interval = 900    # window in which failures are counted

Audit and monitor accounts

# Who is logged in right now, and what are they running?
who
w

# Login history (most recent first), and failed attempts
last -n 20
sudo lastb -n 20

# When did each account last log in?
lastlog | head

# Accounts that have never logged in
lastlog | awk 'NR>1 && /Never logged in/ {print $1}'

# Any account other than root with UID 0 is a red flag
awk -F: '$3==0 {print $1}' /etc/passwd

# Accounts with an empty password field (run as root)
sudo awk -F: '$2=="" {print $1}' /etc/shadow

# Users with a login shell
grep -v -E 'nologin|false' /etc/passwd

# Check the integrity of the account files
sudo pwck -r
sudo grpck -r

# Review sudo usage (systemd journal) or the auth log
sudo journalctl _COMM=sudo --since "1 day ago"
sudo grep sudo /var/log/auth.log        # Debian, Ubuntu
sudo grep sudo /var/log/secure          # RHEL family

Bulk and automated user management

chpasswd and newusers

# Set passwords from a list (user:password per line). Handle this file securely.
sudo chpasswd < passwords.txt

# Create many users from a file (same format as /etc/passwd, with plain passwords)
sudo newusers users.txt

A safe loop for creating team members

#!/usr/bin/env bash
set -euo pipefail
group="devs"
getent group "$group" >/dev/null || groupadd "$group"

while read -r user fullname; do
  if id "$user" &>/dev/null; then
    echo "skip: $user exists"
    continue
  fi
  useradd -m -s /bin/bash -c "$fullname" -G "$group" "$user"
  chage -d 0 "$user"          # force password change at first login
  echo "created: $user"
done < team.txt            # lines like: alice Alice Smith

Configuration management and system accounts

• Ansible: the ansible.builtin.user and ansible.builtin.group modules make user management idempotent and auditable.
• cloud-init: creates the initial admin user and SSH keys on cloud images.
• systemd-sysusers: declares system accounts for services through files in /usr/lib/sysusers.d/. Package maintainers use it so service accounts exist predictably.
• Central identity: for more than a handful of servers, use LDAP, FreeIPA, or Active Directory through SSSD, so accounts are managed once.

# Example: Ansible ad-hoc to ensure a user exists in the devs group
ansible all -b -m ansible.builtin.user -a "name=alice groups=devs append=yes shell=/bin/bash"

Debian family vs Red Hat family

Troubleshooting common errors

Best practices checklist

• Use individual accounts. No shared logins. Every action should trace to a person.
• Apply least privilege. Give the smallest group or sudo rule that does the job, and prefer named commands over blanket access.
• Manage by groups. Assign permissions to groups, then place people in groups.
• Prefer SSH keys with a passphrase, and disable password SSH logins once keys are in place.
• Set password aging where policy requires it, and use chage to set expiry for contractors.
• Offboard fast and completely: lock, expire, kill sessions, remove keys, review files and cron jobs, then delete after the retention period.
• Review regularly. Audit users, sudo and wheel members, UID 0 accounts and never-used accounts every quarter.
• Keep sudoers in drop-ins under /etc/sudoers.d/, edited only with visudo, with change control.
• Centralize identity (LDAP, FreeIPA, AD with SSSD) when you manage more than a few hosts.
• Log and alert on sudo use, new users, group changes and repeated failed logins.
• Test changes safely. Keep one root or console session open when changing sudoers or PAM, and take a snapshot or backup before bulk changes.

Command cheat sheet

If you manage Linux alongside Windows Server, Azure and VMware, more practical admin guides are on VMoreCloud.

Frequently asked questions

Sources and further reading

• Debian manpages: useradd(8)
• Debian manpages: usermod(8)
• Debian manpages: chage(1)
• Debian manpages: gpasswd(1)
• Sudo project: sudoers manual
• sudo-rs project on GitHub
• LinuxConfig: Understanding sudo-rs on Ubuntu 26.04
• systemd: run0 manual

This guide reflects documentation and common administration practice as of October 27, 2026. Command options and defaults can differ between distributions and versions, so check the man pages on your system (man useradd, man sudoers) before running changes in production. Always test account and sudoers changes on a non-production system first and keep a second root session open.

👤 About the Author

Khurram Shahzad

Hybrid Cloud & Virtualization Engineer

Hybrid Cloud & Virtualization Engineer specializing in VMware (VCF, vSAN, Aria), Microsoft Azure, AWS, Windows Server, Microsoft 365, Entra ID, Intune, Linux, Nutanix, Proxmox, networking, backup & disaster recovery, Cisco and FortiGate. I share practical technical guides, infrastructure projects and insights to help IT professionals build and manage modern IT environments through VMoreCloud.

🖥️ VMware🔷 Azure☁️ AWS🪟 Windows Server🐧 Linux🗄️ Virtualization🛡️ Cybersecurity🔗 Networking💾 Backup & DR✖️ Nutanix🟠 Proxmox

📄

120+

Articles Published

👥

10K+

Readers

🎓

Learning & Sharing

A Stronger Tech Community

View all articles →

“Learn  |  Build  |  Share”

☁️ VMoreCloud|Tech Knowledge for a Better Tomorrow

IT  •  Cloud  •  Virtualization  •  Security  •  Open Source