You’ve typed it a hundred times. sudo apt install something. sudo systemctl restart nginx. sudo nano /etc/hosts.
But do you know what’s actually happening? Who decided you’re allowed to use sudo? What is the sudoers file? What happens if you type it wrong?
This is the command that separates beginners from SysAdmins. Let’s make sure you truly understand it.
What is sudo?
sudo stands for “superuser do” (or more precisely, “substitute user do”). It lets a regular user temporarily run a single command with root privileges.
There are two ways to run commands as root:
sudo command— Run ONE command as root, then immediately return to being your normal usersudo suorsu -— Become root for the entire session (risky!)
Always prefer sudo command. Rule: borrow the key, use it, return it. Never hold it.
The Problem sudo Solves
Before sudo, you had two options: run as root all the time (dangerous) or use su to switch to root (also dangerous — easy to forget you’re root).
sudo solves this elegantly:
- You stay logged in as yourself (
shekhar) — a regular user with limited powers - You prefix a command with
sudoto run that specific command as root - The moment the command finishes, you’re a regular user again
- Every sudo action is logged — there’s an audit trail
How sudo Actually Works
You type: sudo apt install nginx
Steps:
1. sudo checks /etc/sudoers — are YOU allowed to run apt?
2. sudo asks for YOUR password (not root's)
3. If sudoers allows it → command runs as root
4. Command finishes → you're back to normal user
5. Action logged to /var/log/auth.logsudo asks for your own password — not the root password.
This is intentional. It verifies you are who you say you are (you know your own password). It also means you don’t need to know the root password at all — which is how most modern Linux servers are set up. Root may not even have a password enabled.
The 15-Minute Cache
After you type your password once, sudo “remembers” it for 15 minutes (by default). During that window, you can run more sudo commands without re-entering your password.
This is the sudo session “token”. It’s stored temporarily in /run/sudo/ts/ per terminal session.
The /etc/sudoers File — Who Gets What
Every sudo permission is controlled by a single file: /etc/sudoers
Reading the Syntax
Every sudoers rule follows this format:
USER HOST=(RUNAS) COMMANDSReal examples:
# Give shekhar full sudo (most common for admin users)
shekhar ALL=(ALL) ALL
# Give 'deploy' user permission to restart nginx WITHOUT a password
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx
# Give 'backup' user permission to run rsync as root (no password)
backup ALL=(root) NOPASSWD: /usr/bin/rsync
# Full sudo with no password (common for automation accounts)
ci-bot ALL=(ALL) NOPASSWD: ALL| Field | Example value | Meaning |
|---|---|---|
USER | shekhar | Which user this rule applies to |
HOST | ALL | Which hosts (servers) this rule applies on. ALL = any host |
(RUNAS) | (ALL) or (root) | Which user to run the command as. (ALL) = any user |
COMMANDS | ALL or /usr/bin/apt | Which commands are allowed. Full path recommended |
NEVER edit /etc/sudoers with a regular text editor (nano, vim, gedit).
If you save a syntax error, you can permanently lock yourself out of sudo — which can mean you can’t fix anything as root either.
Always use: sudo visudo
visudo validates the syntax before saving. If there’s an error, it refuses to save and shows you what’s wrong. It literally cannot lock you out.
Basic sudo Commands
Check if you have sudo access:
List all sudo commands you're allowed to run (reads your sudoers rules)
- •Outputs your full sudo permissions from /etc/sudoers
- •Shows NOPASSWD commands separately
- •If you get 'Sorry, user X is not allowed to run sudo', you're not in sudoers
- •Great for checking what you can do on a new server
Check if you’re in the sudo group:
See all your group memberships — being in 'sudo' (Ubuntu) or 'wheel' (RHEL/CentOS) means you can use sudo
- •Ubuntu/Debian: look for 'sudo' in the output
- •RHEL/CentOS/Fedora: look for 'wheel' in the output
- •If you're not in either, you can't use sudo at all
- •Add a user to sudo group: sudo usermod -aG sudo username
Run a command as root:
Run apt update and upgrade as root — classic sudo usage
- •You'll be asked for YOUR password (not root's)
- •Password is cached for 15 minutes by default
- •Each command must be prefixed with sudo separately (or use sudo -s for a root shell — carefully)
- •The && means: only run upgrade if update succeeded
Edit a root-owned file with sudo:
Open a root-owned config file in nano with elevated privileges
- •/etc/hosts is owned by root — you need sudo to edit it
- •The file opens normally, but credentials are sudo
- •Save with Ctrl+O, exit with Ctrl+X
- •Tip: 'sudo -e /etc/hosts' (sudoedit) is safer — it validates the file after editing
Managing sudo Access
Add a User to sudo (Ubuntu/Debian)
Add user 'alice' to the sudo group — she'll be able to use sudo for all commands
- •Alice must log out and back in for the group change to take effect
- •This gives FULL sudo access — be careful who you grant this to
- •Verify: groups alice — should show 'sudo' in the list
- •On RHEL/CentOS: use 'wheel' group instead of 'sudo'
Add a User to sudo (RHEL/CentOS/Fedora)
On RHEL-based systems, the admin group is called 'wheel' not 'sudo'
- •The 'wheel' group is RHEL tradition — same concept as 'sudo' on Ubuntu
- •The wheel reference comes from 'big wheel' — slang for someone with power
- •The /etc/sudoers file grants the wheel group full sudo by default on RHEL
Grant Specific Command Access (via visudo)
For service accounts and automation, you often want to allow only specific commands:
Open the sudoers file for safe editing — validates syntax before saving
- •visudo uses your $EDITOR (usually nano or vim)
- •Add rules at the END of the file (after all existing rules)
- •Syntax: USER ALL=(ALL) NOPASSWD: /path/to/command
- •You can also drop files in /etc/sudoers.d/ — cleaner for individual rules
Instead of editing /etc/sudoers directly, drop a file in /etc/sudoers.d/:
# Create a file for deploy user's permissions
sudo visudo -f /etc/sudoers.d/deploy
# Add inside:
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginxThis way your custom rules are separate from the default file. Much cleaner for teams and automation.
Advanced sudo Patterns for SysAdmins
Become Root for a Session (Use Carefully)
Start a full root login shell (root's environment, home directory, and all). Exit when done.
- •Unlike 'sudo su', this loads root's full environment (.bashrc, $HOME=/root)
- •You'll see the prompt change: shekhar@server:~$ → root@server:~#
- •The # at the end of the prompt means you're root — be very careful
- •Always type 'exit' as soon as you're done. Never stay in a root shell.
Run as a Different User (Not Root)
Run a command as 'www-data' instead of root — useful for running web app commands with the right file ownership
- •-u specifies which user to run as (not just root)
- •Useful for: running web app commands as www-data so files are owned correctly
- •Useful for: running database scripts as the 'postgres' or 'mysql' user
- •This requires the sudoers file to permit running as that specific user
Reset sudo Timestamp (Require Password Again)
Immediately invalidate your sudo session cache — next sudo will ask for password again
- •Useful after finishing a sensitive task to prevent accidental root commands
- •Great security practice: use -k after any block of admin work
- •Opposite of 'sudo -v' which extends the timeout
Hands-On Challenge
Complete this progression on your Linux machine:
- Check your current sudo permissions:
sudo -l - Open the sudoers file (read-only first):
sudo cat /etc/sudoers— read a few lines - Find which group has sudo power: look for the line
%sudoor%wheel - Check your groups:
groups $(whoami)— confirm you’re in that group - Create a test user:
sudo adduser testuser - Add them to sudo group:
sudo usermod -aG sudo testuser - Verify:
sudo -l -U testuser— see testuser’s permissions - Bonus:
sudo visudo -f /etc/sudoers.d/testuser— add a NOPASSWD rule for one specific command
Key Takeaways
- sudo runs ONE command as root — then you’re back to your normal user. Never stay as root longer than needed.
- sudo asks for YOUR password, not root’s. It verifies identity, not root’s password knowledge.
- All sudo actions are logged —
/var/log/auth.logrecords every command, who ran it, and when. There is no hiding. /etc/sudoerscontrols everything — it defines who can run what commands as whom.- ALWAYS use
sudo visudo— never edit the sudoers file directly. A syntax error can permanently lock you out. - Use
/etc/sudoers.d/for custom rules — cleaner, easier to manage, less risk of breaking the base file. NOPASSWD:is powerful but risky — only use it for automation accounts running specific, safe commands.
How sudo works at a system level, how to read any sudoers rule, how to grant and restrict privileges for users and service accounts, and why visudo is mandatory. You can now manage Linux access control at a professional level — from a home server all the way to production infrastructure.
Next Steps in This Series
- Linux File Permissions: Visual Guide — Now that you control who can use sudo, learn what permissions control file access
- Linux SSH Key Management — Secure your servers with key-based authentication instead of passwords
- What is IAM? — See how the same Users → Groups → Permissions model works in AWS with IAM policies
Test Your Knowledge
Take a quick 5-question quiz to check your understanding.