How to Manage Users and Groups on Linux

Every process on a Linux server runs as some user, and every file belongs to one. Managing users well is how you give a developer access to one site and not another, let a deploy script write files the web server can read, and remove someone's access completely when they leave. The commands are few and the same on every distribution.

Create a user

sudo adduser alice              # Debian/Ubuntu: interactive, creates home, sets password
sudo useradd -m -s /bin/bash alice && sudo passwd alice   # everywhere

-m creates the home directory; -s sets the shell. For an account that should never log in interactively — a service, or an SFTP-only user — set -s /usr/sbin/nologin.

Groups

A group is a list of users; files and directories can grant permissions to a group. See a user's groups:

id alice
groups alice

Add to a group (the -a is essential — without it, usermod -G replaces all secondary groups):

sudo usermod -aG www-data alice

Create a group:

sudo groupadd developers

Changes take effect at the user's next login.

The groups that matter on a web server

• sudo (Ubuntu/Debian) or wheel (EL) — may run commands as root. Membership here is admin access; see creating a sudo user.
• www-data / nginx / apache — the web server's group. A user in it can read files the web server can read.
• psacln and psaserv on Plesk — the group for all subscription users, and the one the web server runs as.

A deploy user for a site

The common need: a developer (or CI) should be able to upload to one site and nothing else, and the web server should be able to read what they upload.

sudo useradd -m -s /bin/bash -d /var/www/example.com deploy-example
sudo usermod -aG www-data deploy-example
sudo chown -R deploy-example:www-data /var/www/example.com
sudo chmod -R g+rX /var/www/example.com
sudo chmod g+s /var/www/example.com          # new files inherit the group

Add their SSH key to /var/www/example.com/.ssh/authorized_keys (owned by them, 700/600). They can now rsync or git pull as deploy-example; Nginx reads via the group; they cannot see /var/www/other-site. The permissions side of this is in file permissions explained.

For SFTP-only users with no shell, add a Match User block in sshd_config with ChrootDirectory and ForceCommand internal-sftp.

Modify a user

sudo usermod -s /usr/sbin/nologin alice     # remove shell access
sudo usermod -d /srv/alice -m alice         # move home
sudo passwd alice                           # reset password
sudo chage -l alice                         # password expiry info
sudo chage -M 90 alice                      # expire every 90 days

Lock and remove

Lock first (reversible), remove later:

sudo usermod -L alice          # lock password
sudo usermod -e 1 alice        # expire the account entirely (also blocks keys)

Then, when sure:

sudo deluser --remove-home alice          # Debian/Ubuntu
sudo userdel -r alice                     # everywhere

Before deleting, find files they own elsewhere, or those files end up with an orphaned numeric owner:

sudo find / -user alice -not -path "/proc/*" 2>/dev/null

Audit who can get in

Users with a real shell:

awk -F: '$7 !~ /(nologin|false)$/ {print $1, $7}' /etc/passwd

Users with sudo:

getent group sudo wheel

SSH keys on the system:

sudo find / -name authorized_keys -not -path "/proc/*" 2>/dev/null | xargs -I{} sh -c 'echo "== {}"; cat {}'

Recent logins and failures:

last -n 20
sudo lastb -n 20

Do this quarterly, and whenever someone leaves. An authorized_keys line from a contractor three years ago is a door that is still open.

Where Plesk fits

Plesk creates one system user per subscription and manages it for you — SSH access is a toggle under Web Hosting Access, keys under the same page, and additional panel users under Users. The commands above still work underneath, but on a Plesk server change access through the panel so it stays in sync. On a VPSPioneer managed VPS we set up the deploy users and keys at handover from the list you give us.