Linux User Accounts and sudo for Business Servers: Named Logins, Least Privilege and Offboarding

The short answer: give every person who touches a Linux server their own named account, grant administrator rights through a group and small files in /etc/sudoers.d edited with visudo, limit people to the commands they actually need, and disable access the same day someone leaves. Then review who has access on a schedule. These habits cost nothing in software, and they turn "someone ran something as root" into a clear, attributable log entry. This guide covers the account side of things on Debian 12/13, Ubuntu 24.04 and RHEL/AlmaLinux 9/10; for the wider baseline, start with our Linux server hardening essentials.

Why shared root logins are a problem

When three people and a vendor all sign in as root with the same password, the server cannot tell them apart. Logs show "root did it", passwords never get changed because changing them breaks everyone, and when a person leaves, the only safe move is to rotate a credential the whole team depends on.

Named accounts fix this:

• Accountability: every login and every sudo command is recorded under a real username.
• Clean offboarding: you disable one account instead of rotating a shared secret.
• Least privilege: each person gets exactly the rights their job requires.

Ubuntu already works this way: the root password is locked by default and the first user administers the system through sudo. On Debian, if you set a root password during installation, you can lock it once your named admin accounts work (sudo passwd -l root). Keep a documented break-glass path, such as console access through your hosting provider, before you do.

Create one account per person

Create the user, set a strong initial password (or none, if they will use SSH keys), and add them to the right groups.

## Debian / Ubuntu
sudo adduser maria

## RHEL / AlmaLinux
sudo useradd -m maria
sudo passwd maria

Never reuse a former employee's account for a new hire, and avoid generic names such as admin or support. If a vendor needs access, they get their own account with an expiry date (more on that below).

Grant sudo through groups, not individuals

Both distribution families ship a group that already has full sudo rights:

Distribution	Admin group	Add a user
Debian 12/13, Ubuntu 24.04	sudo	sudo usermod -aG sudo maria
RHEL / AlmaLinux 9/10	wheel	sudo usermod -aG wheel maria

The -a (append) flag matters: without it, usermod -G replaces the user's supplementary groups. The change applies at the user's next login.

Full administrators should be a short list. Most people who need elevated rights only need a few specific commands.

Use /etc/sudoers.d and always edit with visudo

Do not edit /etc/sudoers directly. Put your rules in small drop-in files under /etc/sudoers.d/, and always open them with visudo, which checks the syntax before saving. A broken sudoers file can lock every administrator out of sudo.

sudo visudo -f /etc/sudoers.d/20-webops
sudo visudo -c   # check every sudoers file for syntax errors

One detail that catches people out: sudo skips files in that directory whose names contain a . or end in ~. A file called webops.conf is silently ignored. Use names like 20-webops.

Restrict commands for least privilege

Instead of ALL, list the exact commands a role needs. For example, a web team that only restarts services:

## /etc/sudoers.d/20-webops
Cmnd_Alias WEB_SERVICES = /usr/bin/systemctl reload nginx, \
                          /usr/bin/systemctl restart nginx, \
                          /usr/bin/systemctl restart php8.3-fpm
%webops ALL=(root) WEB_SERVICES

Then create the group and add people to it:

sudo groupadd webops
sudo usermod -aG webops maria
sudo -l -U maria   # confirm what maria may run

A few rules keep restrictions meaningful:

• Use full paths to commands, never bare names.
• Do not grant editors, pagers or shells (vim, less, bash, find, tar and similar) as root. Many of them can start a shell, which turns a narrow rule into full root. To let someone edit a file, use a sudoedit rule instead.
• Avoid "everything except" rules such as ALL, !/bin/su. The sudoers manual and Red Hat's documentation both warn that negative rules are easy to bypass.
• Use NOPASSWD sparingly, ideally only for automation accounts with a tightly limited command list.

Make sure sudo activity is logged

Sudo logs every successful and denied attempt by default. Where it lands depends on the system:

• RHEL / AlmaLinux: the journal and /var/log/secure.
• Ubuntu 24.04: the journal and /var/log/auth.log.
• Debian 12/13: the journal (rsyslog, and so /var/log/auth.log, is not installed by default).

sudo journalctl _COMM=sudo --since "7 days ago"

For sensitive servers you can also record full terminal sessions run through sudo. Add a drop-in such as /etc/sudoers.d/10-logging:

Defaults log_output
Defaults logfile=/var/log/sudo.log

Recorded sessions can be listed and replayed with sudoreplay -l. They can contain sensitive data, so protect them and include them in your retention rules. Forward these logs off the server, too: an attacker with root can edit local files.

Offboarding: disable access the same day

When someone leaves, or a contractor's work ends, act immediately. Note that locking a password alone does not stop SSH key logins. The passwd manual says so explicitly, and the usermod manual advises also setting the expiry date to lock the whole account.

## 1. Lock the password and expire the account
sudo usermod -L -e 1 maria

## 2. Remove SSH keys
sudo mv /home/maria/.ssh/authorized_keys /root/maria-authorized_keys.disabled

## 3. End any running sessions and processes
sudo loginctl terminate-user maria
sudo pkill -KILL -u maria

## 4. Remove admin rights
sudo gpasswd -d maria sudo      # or: wheel

Then check for anything still running under that name, such as sudo crontab -l -u maria and systemd user timers, and rotate any shared secrets the person knew (database passwords, API keys). Delete the account later, according to your retention policy, once you have confirmed nothing depends on it. Our employee onboarding and offboarding IT checklist covers the non-server side.

Give temporary accounts an expiry date

For vendors and short projects, set the end date when you create the account:

sudo chage -E 2026-12-31 vendor-acme
sudo chage -l vendor-acme

Password aging: use it carefully

chage can force regular password changes (-M), but current NIST guidance (SP 800-63B) says verifiers should not require periodic changes and should force a change only when there is evidence of compromise. Forced rotation tends to produce weaker, predictable passwords. A better approach for servers:

• Prefer SSH keys for interactive logins, and protect them as covered in your SSH policy.
• Use long, unique passwords for sudo, stored in a team password manager.
• Use chage -E for real end dates, and change a password immediately if you suspect it was exposed.

Service accounts: no shell, no password

Applications such as a web app, a backup agent or a queue worker should run under their own system account that nobody can log in as:

sudo useradd --system --shell /usr/sbin/nologin \
  --home-dir /var/lib/myapp --create-home myapp

System accounts created this way have no usable password. The nologin shell refuses interactive logins. Give the account ownership of only its own files, and if it needs one privileged action, write a narrow sudoers rule for that command alone.

Review access every quarter

Accounts accumulate. A short, recurring review catches the leftovers:

## Who can administer this server?
getent group sudo wheel webops

## Which accounts have a real login shell?
cut -d: -f1,7 /etc/passwd | grep -v -E 'nologin|false'

## Last logins (newer releases replace lastlog with lastlog2)
lastlog 2>/dev/null || lastlog2

For each account, ask: does this person still work here, do they still need this level of access, and when did they last use it? Record the review date and any changes. Many compliance frameworks expect periodic access reviews, and a dated record makes that easy to show.

Need help cleaning up server access?

If your Linux servers still run on shared root passwords or nobody is sure who has sudo, we can help. Core Florida IT sets up named accounts, least-privilege sudo rules and offboarding procedures for businesses in Miami-Dade and across South Florida, as part of our server setup and repair and cybersecurity services. Request a free IT assessment and we will review who can access your servers and what they can do.

Sources

• sudoers manual (sudo project)
• Managing sudo access, RHEL 9 documentation (Red Hat)
• User management, Ubuntu Server documentation (Canonical)
• usermod(8) manual page
• chage(1) manual page
• NIST SP 800-63B: Authentication and Authenticator Management