sudo lets permitted users run commands as root (or another user) without sharing the root password. Every use is logged, permissions can be limited to specific commands, and it’s the standard way to administer a Linux server.

Using sudo

sudo apt update                 # run one command as root
sudo -i                         # root login shell
sudo -s                         # root shell keeping your environment
sudo -u www-data php artisan    # run as another user
sudo -l                         # what am I allowed to run?
sudo -k                         # forget cached credentials now

After you authenticate, sudo caches it for 15 minutes per terminal by default.

Giving a user sudo rights

The simplest way: add them to the admin group.

sudo usermod -aG sudo alice      # Debian/Ubuntu
sudo usermod -aG wheel alice     # AlmaLinux/Rocky/Fedora

The user must log out and back in. The group is enabled by a line in /etc/sudoers:

%sudo   ALL=(ALL:ALL) ALL        # Debian/Ubuntu
%wheel  ALL=(ALL)     ALL        # RHEL family

Always edit sudoers with visudo

A syntax error in sudoers can lock everyone out of sudo. visudo checks syntax before saving:

sudo visudo                               # main file
sudo visudo -f /etc/sudoers.d/deploy      # a drop-in file
sudo visudo -c                            # check all files

Put your own rules in drop-in files under /etc/sudoers.d/ rather than editing the main file. Drop-in file names must not contain a dot or end with ~, or they’re ignored. Permissions must be 0440.

Rule syntax

WHO    WHERE=(AS_WHOM)   WHAT
alice  ALL=(ALL:ALL)     ALL
  • WHO — a user, or %group.
  • WHERE — host (almost always ALL).
  • AS_WHOM — (user:group) the commands may run as.
  • WHAT — commands, with full paths, or ALL.

Limit users to specific commands

A deploy user that may only restart the app and reload Nginx:

# /etc/sudoers.d/deploy
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp, /usr/bin/systemctl reload nginx

Rules:

  • Use absolute paths (command -v systemctl to find them).
  • Be specific with arguments: systemctl restart myapp — not systemctl *, which would allow systemctl edit and much more.
  • Beware of commands that allow escapes to a shell: editors (vi, less), find -exec, tar --checkpoint-action, scripting interpreters. Granting sudo vim effectively grants root.

NOPASSWD for automation

CI pipelines and scripts can’t type passwords. NOPASSWD: allows a command without prompting — restrict it to exactly what the automation needs, as above. Avoid NOPASSWD: ALL for accounts used by scripts; a leaked deploy key would then mean full root access.

Run commands as another non-root user

alice ALL=(www-data) NOPASSWD: /usr/local/bin/wp
sudo -u www-data wp plugin list

Aliases for larger setups

Cmnd_Alias WEB = /usr/bin/systemctl reload nginx, /usr/bin/systemctl restart php8.3-fpm
User_Alias WEBADMINS = alice, bob
WEBADMINS ALL=(root) WEB

Useful Defaults

Defaults timestamp_timeout=5            # ask again after 5 minutes
Defaults logfile=/var/log/sudo.log      # separate log file
Defaults log_input, log_output          # record full sessions (sudoreplay)
Defaults use_pty                        # safer handling of background processes

Auditing

Every sudo command is logged:

sudo journalctl _COMM=sudo --since today
sudo grep sudo /var/log/auth.log | tail      # Debian/Ubuntu with rsyslog

Lines show who ran what, from which terminal, as whom, and whether it was allowed. See sudo logging for session recording.

Locked out of sudo?

If a broken sudoers file blocks sudo:

  • If root has a password: su - then visudo to fix.
  • pkexec visudo works on some systems with polkit.
  • Otherwise use your VPS’s VNC console and boot into rescue mode to fix /etc/sudoers.

Prevention: always use visudo, and keep a second root session open while changing sudo rules.

Good practice

  • Personal accounts for everyone; no shared admin user.
  • Disable direct root SSH login — see disable root SSH login.
  • Full sudo only for real administrators; command-limited rules for automation.
  • Review /etc/sudoers.d/ and the sudo/wheel group membership regularly.

Related: create users and the Linux server hardening checklist.

  • Linux
  • sudo
  • Security