Users, permissions, and processes / Stage 8 of 13 · step 7 of 8

Suspend a user account

~20 min

Not running Starting usually ~20 s

Situation

An employee who worked under the labpaused account is handing over their duties. Until the handover is done, the account has to be suspended: no one may log in to it, either with the password or with an SSH key. Deleting it is premature — the home directory holds handover notes, and a background process of labpaused has been agreed to keep running until the handover ends.

Task

The labpaused password is locked, and the password itself is neither deleted nor replaced: access must be restorable.
The account has expired — its end date is in the past.
The login shell is /usr/sbin/nologin, and the home directory in the record is unchanged.
The key from /home/labpaused/.ssh/authorized_keys no longer works: there's no active key file, and an exact copy of it sits in /srv/account-review/authorized_keys.saved, readable by root only (owner root:root, mode 600).
The home directory, .ssh and notes.txt are in place with their original owner and mode, and notes.txt is unchanged; other accounts, sudo and SSH settings are untouched.
The background process of labpaused keeps running — the same one that was started.

Constraints

Don't delete the account and don't kill labpaused's processes.
Account changes need sudo.

The tools you need are already installed. There's no internet on this machine.

Lab goals

0 of 6

labpaused's password is locked and the original one is kept — not checked yet
The account has expired — its end date is in the past — not checked yet
The login shell is /usr/sbin/nologin and the home directory is unchanged — not checked yet
The key from authorized_keys no longer works and its copy is readable by root only — not checked yet
The home directory, .ssh and notes.txt are kept; other accounts and settings are untouched — not checked yet
The original background process of labpaused keeps running — not checked yet

Hints

0 of 3 open · they open one at a time

Hint 1

Show the solution after 3 failed checks

Users and permissions · picked for this lab

Users and groups

Cheat sheet

$_ — insert into the terminal

id alice uid/gid/groups
sudo useradd -m -s /bin/bash bob create
sudo usermod -aG sudo bob add to a group (with -a, or it replaces all)
sudo passwd bob set a password
sudo passwd -l bob lock password login
sudo chage -M 90 bob maximum password age — 90 days
getent group sudo who's in the group

Management

bash

sudo useradd -m -s /bin/bash alice    # create (with a home directory -m and shell)
sudo passwd alice                      # set a password
sudo usermod -aG sudo alice            # ADD to a group (the -a matters, or it replaces!)
sudo usermod -aG docker,www-data alice
sudo usermod -s /usr/sbin/nologin svc  # forbid interactive login (a service account)
sudo gpasswd -d alice docker           # remove from a group
sudo userdel -r alice                  # delete along with the home directory
sudo groupadd devs                     # create a group
sudo groupdel devs                     # delete a group
adduser bob                            # the interactive wrapper (Debian/Ubuntu)

A common mistake. usermod -G grp without -a replaces all of a user's supplementary groups — use usermod -aG, not -G. The template for a new home directory is /etc/skel.

Passwords, locking, su

bash

sudo passwd -l alice              # lock the password (password login forbidden)
sudo passwd -u alice              # unlock it
sudo usermod -L / -U alice        # the same (lock/unlock)
sudo chage -l alice               # the password aging policy
sudo chage -M 90 -W 7 alice       # max age 90 days, warn 7 days ahead
sudo chage -E 2026-12-31 alice    # the account's expiration date
sudo passwd -e alice              # require a password change at next login

su - bob                          # become bob (a login shell, its own environment)
su -                              # become root (if you know root's password)
sudo -u postgres -i               # better: through sudo, no root password needed (see sudo)

System users (daemons) usually have uid < 1000, nologin, no password (useradd -r).

Added to a group — it has no effect

Group membership applies on the next login. Log back in (or use newgrp <group> for the current shell). Check with id.

Accidentally replaced the groups (`-G` without `-a`)

Restore the needed ones: usermod -aG sudo,docker alice. You can verify against /etc/group (getent group).

Can't delete a user — "currently used by process"

End its processes (pkill -u alice, see processes) or use userdel -f.

Login denied, even though the password is correct

The account/password is locked (passwd -l/chage -E in the past) or the shell is nologin. Check chage -l, getent passwd (the last field is the shell).

Files show the "wrong" group

An SGID directory only assigns its group to NEW files; recursively chgrp -R the old ones (see permissions, chmod-chown).

userdel -r deletes the home directory and mail spool irreversibly — without a backup, the data cannot be recovered. Before deleting, check whether any processes or cron jobs still belong to the user (pkill -u, crontab -l -u): userdel without -f refuses to delete an account with active processes, while -f deletes it anyway, even if processes keep running under the now-nonexistent UID. After deletion, the freed UID can be reassigned to a new user — files left on disk with that UID become "theirs".