Sudo for Beginners: Run Linux Commands with Elevated Privileges Safely

Introduction

If you have spent any time on a Linux system, you have probably typed sudo before a command without really thinking about why. sudo (short for “substitute user do”) is the standard way to run commands with elevated privileges on Linux — without logging in as root.

Understanding how sudo works is not just a nice-to-have. It is the foundation of safe Linux administration. Get it wrong and you open the door to accidental system damage or security vulnerabilities. Get it right and you have precise, auditable control over who can do what on your machines.

This guide walks you through exactly that — from how sudo works, to reading the sudoers file, to granting and restricting access the right way.

Why Does This Matter?

• Security: Running everything as root is dangerous. sudo lets you grant just enough privilege to just the right users, reducing your attack surface significantly.
• Auditability: Every sudo command is logged. You get a full trail of who ran what, and when — invaluable for incident response and compliance.
• Industry standard: Every major Linux distribution and DevOps workflow relies on sudo. Knowing it well is a baseline skill for any sysadmin, developer, or platform engineer.

How sudo Works

When you prefix a command with sudo, Linux checks whether the current user is authorised to run that command with elevated privileges. That authorisation is defined in the sudoers file at /etc/sudoers.

If the user is allowed, sudo prompts for their own password (not root’s), runs the command, and logs the action to syslog.

# Check your sudo version
sudo --version

The sudoers file is never edited directly with a text editor — always use visudo, which validates syntax before saving and prevents you from accidentally locking yourself out.

sudo visudo

Understanding the sudoers File

Open /etc/sudoers (via visudo) and you will see lines that look like this:

root    ALL=(ALL:ALL) ALL
%sudo   ALL=(ALL:ALL) ALL
john    localhost=/usr/bin/systemctl restart nginx

Each line follows a four-part pattern. Here is what each position means:

A line like daisy ALL=(root) /usr/bin/apt means: on any host, daisy can run /usr/bin/apt as root.

Pro-tip: Always use full paths in the sudoers file (e.g. /usr/bin/systemctl not just systemctl). Relative paths are a security risk because they depend on the user’s $PATH.

Step 1: Check Who Already Has sudo Access

Before making any changes, see which users and groups currently have sudo privileges:

# List all sudoers rules (requires root or existing sudo access)
sudo cat /etc/sudoers

# Also check drop-in files in the sudoers.d directory
sudo ls /etc/sudoers.d/

On most Ubuntu/Debian systems, members of the sudo group have full access. On RHEL/CentOS, it is the wheel group.

# Check which group a user belongs to
groups daisy

Step 2: Grant sudo Access to a User

The cleanest approach is to add the user to the appropriate system group rather than editing sudoers directly.

# On Ubuntu/Debian
sudo usermod -aG sudo daisy

# On RHEL/CentOS/Fedora
sudo usermod -aG wheel daisy

The user needs to log out and back in for the group change to take effect.

If you need a more targeted rule — say, allowing a deploy user to restart a service but nothing else — add a drop-in file under /etc/sudoers.d/:

sudo visudo -f /etc/sudoers.d/deploy-rules

Inside that file:

# Allow the deploy user to restart nginx only
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

Pro-tip: NOPASSWD: skips the password prompt. This is useful for automation and CI/CD pipelines, but use it selectively — only for specific, low-risk commands.

Step 3: Run Commands with sudo

With access configured, using sudo is straightforward:

# Run a single command as root
sudo apt update

# Run a command as a different user entirely
sudo -u www-data ls /var/www/html

# Open an interactive root shell (use sparingly)
sudo -i

# Run the last command again with sudo
sudo !!

Step 4: Verify the Configuration Works

Test that the user’s sudo access is set up correctly before relying on it:

# Check what sudo privileges the current user has
sudo -l

# Check privileges for a specific user (run as root)
sudo -l -U daisy

Expected output for a fully privileged user looks like:

User daisy may run the following commands on this host:
    (ALL : ALL) ALL

For a restricted user with only the nginx restart rule:

User deploy may run the following commands on this host:
    (root) NOPASSWD: /usr/bin/systemctl restart nginx

Troubleshooting

• “daisy is not in the sudoers file. This incident will be reported.” — The user has not been added to the sudo/wheel group, and there is no matching rule in sudoers. Add them via usermod -aG sudo daisy and ensure they re-login.

• “syntax error in /etc/sudoers” — This is why you always use visudo. If you somehow ended up with a broken sudoers file, boot into recovery mode or use pkexec visudo to fix it without sudo access.

• sudo prompts for a password even with NOPASSWD — Check that the NOPASSWD: tag appears before the command in the rule, and that no earlier rule in the file is overriding it. Rules are evaluated top-to-bottom; the last match wins.

• Group membership not taking effect — The user must log out and back in (or run newgrp sudo) after being added to a group. groups will still show the old groups in the current session.

Conclusion

sudo is one of those things that looks simple on the surface but has a lot of depth once you start managing real systems. The key principles to take away: keep your rules specific, use drop-in files under /etc/sudoers.d/ rather than editing the main file, always use visudo, and lean on group-based access over per-user rules where possible.

Once you are comfortable here, the next step is exploring sudo logging in /var/log/auth.log and integrating privilege management with tools like Ansible or your organisation’s IAM solution.

Happy Engineering!