sudo

What sudo is and how it works

sudo (pronounced "su-do") runs a command as the superuser or another user when a security policy allows it. According to the sudo manual, the policy is checked against the invoking user's real user ID, and the default policy, sudoers, is configured in /etc/sudoers. When authentication is required, sudoers validates the invoking user's own credentials, not the target user's, so administrators never need to share the root password.

That is the main difference from su. The su manual says it defaults to "an interactive shell as root" and leaves access rules such as wheel-group membership to PAM. sudo works per command instead: the policy can limit which commands a person may run, on which host and as which user, and the sudo project describes the result as an audit trail of commands and their arguments. The rules themselves are covered on the sudoers page, and the surrounding idea is least privilege.

Everyday commands and a safe way to test

These forms cover most daily use:

sudo -l                  # list what you may run on this host
sudo -u www-data id      # run one command as another user
sudo -i                  # login shell of the target user (root by default)
sudo -s                  # shell named in $SHELL
sudo -v                  # refresh cached credentials
sudo -k                  # forget cached credentials for this session
sudo -n true             # fail instead of asking for a password
sudoedit /etc/hosts      # edit a temporary copy, copy back if changed

The manual says -i runs the target user's shell as a login shell, reads its login files and changes to its home directory, while -s runs the shell from SHELL or the passwd entry. Both give you an interactive root shell, so prefer one-off commands. To check a rule without risk, run sudo -k then sudo -n true: it exits with an error if a password would be needed or the command is not permitted. Administrators can inspect another account with sudo -l -U deploy.

Caching, logging and common mistakes

• Credential caching. The sudoers manual gives timestamp_timeout a default of 5 minutes, kept per terminal (timestamp_type defaults to tty). A value of 0 always prompts, and a negative value never expires until reboot.
• Shells hide detail. After sudo -i the log shows that a shell started. Recording what is typed inside needs log_input or log_output, both off by default.
• Where it logs. Logging goes to syslog unless you set a log file. Allowed commands are logged at notice, denied commands and failed authentication at alert, and three password tries are allowed by default.
• Broad rules. Once sudo runs a program, that program can start others, so allowing editors, pagers or ALL defeats the control.
• Passwordless rules. NOPASSWD means a stolen session or key is a root shell.

sudo is itself privileged software, so keep it updated, as the patch management guide explains.

Where sudo fits in server hardening

On a VPS, sudo is the tool that turns least privilege into practice: each person logs in as a named account with a key, direct root login stays off, and administrative work is elevated one command at a time. Put your own rules in /etc/sudoers.d, keep each one narrow, and audit them on a schedule. The users, sudo and least privilege guide walks through that audit and the sudo CVE worth patching, and the SSH hardening guide covers turning off root over SSH.

Review who can elevate and what happened recently:

getent group sudo wheel
sudo journalctl _COMM=sudo --since today

On systemd hosts the journal collects sudo's syslog messages, and _COMM= matches the process name; elsewhere read your distribution's auth log. Because full sudo access turns one stolen key into root, add a second factor for SSH for administrators, and feed these logs into the log monitoring guide.

Related terms: sudoers, Least privilege, Root login, PAM, UID 0.