If you use Linux long enough, you’ll eventually run into a command that works perfectly as your normal user—but suddenly fails with:

Permission denied

The usual solution is:

sudo

Most Linux users learn sudo by memorizing a simple pattern:

sudo command

But sudo does much more than temporarily give you root access.

It can control who is allowed to run which commands, on which hosts, as which users, and under what conditions. It can also keep an audit trail of administrative actions, which makes it an important part of Linux security rather than just a convenient shortcut.

In this guide, we’ll start with the basics and gradually move into practical administration, configuration, troubleshooting, and security.

What Is sudo?

sudo stands for “superuser do.”

It allows an authorized user to run a command with the privileges of another user, usually root.

For example:

sudo systemctl restart nginx

Your shell is still running as your normal user. Only the command executed through sudo runs with elevated privileges.

See also: Mastering the Linux Command Line — Your Complete Linux Training Course

You can verify this with:

whoami

and:

sudo whoami

You might see:

$ whoami
alice

$ sudo whoami
root

This distinction is important.

sudo does not normally turn your entire shell into a root shell. It elevates the privileges of the command you explicitly run.

---

Why Does Linux Need sudo?

Linux separates ordinary users from privileged users for a reason.

A normal user shouldn’t be able to casually:

• Modify system files
• Install system-wide software
• Change network configuration
• Start or stop critical services
• Change file ownership
• Create or delete system accounts
• Modify security policies

For example:

rm /etc/some-important-file

will normally fail for an ordinary user.

But:

sudo rm /etc/some-important-file

may succeed.

That’s precisely why sudo should be treated carefully.

A typo in a normal command might affect your own files.

A typo in a command run with sudo can affect the entire machine.

---

How sudo Works

When you run:

sudo command

Linux goes through several steps.

At a high level:

User
  |
  v
sudo
  |
  +--> Check sudo policy
  |
  +--> Authenticate user if required
  |
  +--> Determine target user
  |
  +--> Execute command
  |
  v
Privileged process

The policy is normally configured through:

/etc/sudoers

and additional configuration files under:

/etc/sudoers.d/

You can inspect your current permissions with:

sudo -l

For example:

User alice may run the following commands:
    (ALL) ALL

This means the user has broad sudo privileges.

---

The Basic sudo Syntax

The simplest form is:

sudo command

For example:

sudo dnf update

or:

sudo systemctl restart sshd

You can also pass arguments normally:

sudo systemctl status nginx

The general syntax is:

sudo [options] command [arguments]

For example:

sudo -u postgres psql

This tells sudo to run psql as the postgres user instead of root.

---

sudo Does Not Mean “Run Everything as Root”

This is one of the most useful things to understand about sudo.

Consider:

sudo systemctl restart nginx

Only systemctl is executed with elevated privileges.

Your shell remains your normal shell.

You can see the difference with:

whoami
sudo whoami
whoami

The output might be:

alice
root
alice

This is one reason sudo is safer than routinely logging in as root.

---

Running a Command as Another User

sudo isn’t limited to root.

Use:

sudo -u username command

For example:

sudo -u postgres psql

This is extremely common on database servers.

You can check:

sudo -u postgres whoami

Output:

postgres

You can also run a shell as another user:

sudo -u postgres bash

However, be careful with interactive shells. If you only need to execute one command, running that command directly is usually clearer.

---

Running a Login Shell as Another User

You may sometimes see:

sudo -iu postgres

The options mean:

• -i — start an interactive login shell
• -u postgres — run it as postgres

For example:

sudo -iu postgres

Now:

whoami

returns:

postgres

This is commonly useful when administering PostgreSQL.

---

The Most Useful sudo Option: -l

One of the first commands I recommend running on a new server is:

sudo -l

It shows what the current user is allowed to run through sudo.

For example:

User alice may run the following commands:
    (ALL) /usr/bin/systemctl restart nginx
    (ALL) /usr/bin/systemctl status nginx

This is very different from:

(ALL) ALL

The first configuration grants specific permissions.

The second grants much broader access.

Understanding this distinction is important when designing least-privilege access.

---

Checking sudo Version

You can check the installed version with:

sudo --version

Example:

Sudo version 1.9.x
Sudoers policy plugin version 1.9.x
Sudoers I/O plugin version 1.9.x

The exact output depends on the Linux distribution and installed sudo version.

---

sudo Password Caching

You may have noticed something interesting.

Run:

sudo ls /root

Enter your password.

Then immediately run:

sudo id

You might not be asked for your password again.

That’s because sudo normally caches successful authentication for a period of time.

You can see the timestamp-related behavior with:

sudo -v

The -v option means validate.

It doesn’t normally execute a command. It refreshes your sudo authentication credentials.

---

Resetting sudo Authentication

If you want to force sudo to ask for your password again:

sudo -k

Then:

sudo id

should normally prompt for authentication again.

You can also use:

sudo -K

which removes the user’s cached credentials more completely.

The distinction is subtle, but useful when testing sudo authentication behavior.

---

Running Commands Without a Password

Administrators can configure sudo so that specific commands don’t require a password.

For example, a sudoers rule might look like:

alice ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

Now Alice can run:

sudo systemctl restart nginx

without entering a password.

This can be useful for automation.

But there’s an important security consideration:

Don’t use NOPASSWD: ALL unless you have a very good reason.

Giving unrestricted passwordless sudo is effectively giving the user unrestricted administrative access.

---

The sudoers File

The main sudo configuration file is:

/etc/sudoers

You can inspect it with:

sudo cat /etc/sudoers

However, do not casually edit it with a normal text editor.

Instead, use:

sudo visudo

Why?

Because visudo validates the syntax before installing the new configuration.

A syntax error in /etc/sudoers can prevent users from using sudo.

That’s a particularly unpleasant way to lock yourself out of administrative access.

---

Why You Should Use visudo

Suppose someone accidentally writes:

alice ALL=(ALL ALL

instead of a valid rule.

A normal editor will happily save it.

visudo, however, checks the configuration and can report the syntax problem before the file is accepted.

The basic rule is:

If you’re modifying sudoers, use visudo.

---

The /etc/sudoers.d Directory

Modern Linux systems commonly use:

/etc/sudoers.d/

for additional sudo configuration.

For example:

/etc/sudoers.d/web-admin
/etc/sudoers.d/database-admin
/etc/sudoers.d/monitoring

This is often cleaner than putting every rule directly into /etc/sudoers.

A typical configuration might be:

alice ALL=(ALL) /usr/bin/systemctl restart nginx

Then Alice can run:

sudo systemctl restart nginx

but doesn’t automatically receive permission to run arbitrary commands as root.

---

Understanding sudoers Syntax

A sudoers rule can look intimidating at first:

alice server01=(root) /usr/bin/systemctl restart nginx

Break it down:

alice

The user.

server01

The host where the rule applies.

(root)

The user the command runs as.

/usr/bin/systemctl restart nginx

The command that is allowed.

A more general rule:

alice ALL=(ALL) ALL

means Alice can run any command as any user on all hosts covered by that rule.

---

Groups Can Use sudo Too

Instead of assigning sudo permissions to individual users, administrators often assign them to groups.

For example:

%wheel ALL=(ALL) ALL

The % indicates a Unix group.

On many Linux distributions, members of the wheel group can use sudo.

Check group membership with:

id

or:

groups

For example:

uid=1001(alice) gid=1001(alice) groups=1001(alice),10(wheel)

You can add a user to a group with:

sudo usermod -aG wheel alice

On some distributions, the administrative group may instead be called sudo.

For example, Debian and Ubuntu commonly use:

sudo usermod -aG sudo alice

---

sudo vs su

These commands are often confused.

su means switch user.

For example:

su -

starts a root login shell if the root account is enabled and the authentication succeeds.

sudo, on the other hand, is designed to execute commands with another user’s privileges.

For example:

sudo systemctl restart nginx

You don’t need to switch into a root shell first.

A useful mental model is:

su
|
+--> Switch identity / shell

sudo
|
+--> Execute a specific command with another identity

---

sudo vs sudo -i

These are also different:

sudo command

runs one command with elevated privileges.

sudo -i

starts an interactive root login shell.

For example:

sudo -i

then:

whoami

returns:

root

Once you’re finished:

exit

returns you to your normal shell.

For routine administration, executing the specific command with sudo is often easier to audit than spending a long time inside a root shell.

---

sudo -s vs sudo -i

You may also encounter:

sudo -s

and:

sudo -i

They aren’t identical.

sudo -s starts a shell using the current user’s environment as a starting point.

sudo -i simulates an initial login environment for the target user.

You can compare them with:

sudo -s

and:

sudo -i

and inspect:

whoami
echo $HOME
echo $USER
pwd

The differences can matter when environment variables, shell startup files, or user-specific configuration are involved.

---

A Common sudo Mistake: Using sudo with cd

This won’t work the way many beginners expect:

sudo cd /some/directory

You may get:

sudo: cd: command not found

Why?

Because cd is normally a shell builtin, not a standalone executable.

Instead, use:

cd /some/directory

If you don’t have permission to access the directory, start a privileged shell:

sudo -i
cd /some/directory

Or run the required command directly with sudo.

---

Another Common Mistake: sudo echo

Suppose you want to add text to a root-owned file:

sudo echo "hello" >> /etc/example.conf

This may fail with:

Permission denied

The reason is subtle.

The shell handles:

>>

before sudo runs echo.

So the redirection is performed by your normal shell.

A common solution is:

echo "hello" | sudo tee -a /etc/example.conf

Now tee itself runs with elevated privileges.

You can also use:

sudo sh -c 'echo "hello" >> /etc/example.conf'

But be careful with quoting when commands become more complex.

---

sudo and Environment Variables

By default, sudo does not simply pass your entire environment to the privileged command.

For example:

sudo env

may show a much smaller or sanitized environment than:

env

This is intentional.

Environment variables can influence program behavior, so blindly preserving them could create security problems.

For example:

sudo -E command

asks sudo to preserve the user’s environment.

Use this carefully.

-E does not magically make an environment safe. Whether variables are preserved also depends on sudoers policy.

---

sudo and PATH

Another important security concept is the executable path.

Compare:

sudo systemctl restart nginx

with:

sudo /usr/bin/systemctl restart nginx

Using the absolute path can make sudoers rules more precise.

For example:

alice ALL=(root) /usr/bin/systemctl restart nginx

is much more restrictive than:

alice ALL=(root) ALL

When building least-privilege rules, administrators should know exactly which executable is being authorized.

You can locate a command with:

command -v systemctl

or:

which systemctl

---

Understanding “sudo: command not found”

If you see:

sudo: command not found

it usually means sudo isn’t installed or isn’t available through your current PATH.

Check:

command -v sudo

On RPM-based systems:

rpm -q sudo

On Debian-based systems:

dpkg -l sudo

If sudo isn’t installed, installation depends on your distribution.

For example, on RHEL, Rocky Linux, or Fedora:

sudo dnf install sudo

On Debian or Ubuntu:

sudo apt install sudo

If you don’t already have administrative access, you’ll need another way to obtain the required privileges.

---

Understanding “User is not in the sudoers file”

A common error is:

alice is not in the sudoers file.
This incident will be reported.

This means the user doesn’t currently have permission to use sudo.

You need to check:

sudo -l

If that isn’t possible, an administrator must grant the appropriate permissions.

On a RHEL-like system, this might mean adding the user to wheel:

usermod -aG wheel alice

On Ubuntu/Debian:

usermod -aG sudo alice

The user may need to start a new login session before the new group membership becomes effective.

---

How to Check Whether sudo Works

A quick test is:

sudo -v

If authentication succeeds, you can then test:

sudo id

For example:

uid=0(root) gid=0(root) groups=0(root)

You can also check the exact permissions:

sudo -l

These three commands are useful when troubleshooting:

id
sudo -l
sudo id

Together, they tell you:

1. Who you are
2. What sudo allows
3. Which identity the command actually runs as

---

sudo Logging and Auditing

One of sudo’s biggest advantages in enterprise environments is auditing.

Depending on the system’s configuration, sudo activity can be logged through system logging facilities or other audit mechanisms.

You might find sudo-related records with commands such as:

journalctl | grep sudo

or:

grep sudo /var/log/secure

On Debian or Ubuntu systems, you may find records in:

/var/log/auth.log

For example:

sudo journalctl -u sudo

may not always return what you expect because sudo itself is not necessarily a systemd service.

Instead, search the system journal:

sudo journalctl | grep sudo

The exact logging location depends on the Linux distribution and logging configuration.

---

sudo and Automation

Automation introduces another important question:

Should an automated process be allowed to use sudo?

For example, an Ansible playbook might execute:

sudo systemctl restart nginx

A password prompt would obviously be inconvenient for automation.

That’s where carefully scoped NOPASSWD rules can be useful.

Instead of:

deploy ALL=(ALL) NOPASSWD: ALL

you might authorize only the required command:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

This follows the principle of least privilege much more closely.

---

The Principle of Least Privilege

One of the most important lessons from sudo is this:

Give users only the privileges they actually need.

Suppose an operations user only needs to restart Nginx.

This:

ops ALL=(root) /usr/bin/systemctl restart nginx

is more restrictive than:

ops ALL=(ALL) ALL

The second rule effectively gives the user unrestricted administrative capabilities.

The first rule provides a much narrower permission.

This difference becomes especially important on production systems.

---

Be Careful With Wildcards

Sudoers supports patterns and wildcards, but overly broad patterns can create unexpected privileges.

For example:

alice ALL=(root) /usr/bin/some-command *

might look harmless.

But if the command accepts arguments that allow users to execute other programs, modify files, or escape into a shell, the sudo rule may provide far more access than intended.

When creating sudo rules, don’t just ask:

“Does this command look safe?”

Ask:

“What can someone make this command do with arbitrary arguments?”

That’s a much better security question.

---

A Practical sudo Troubleshooting Workflow

When someone says:

“sudo doesn’t work.”

Don’t immediately modify /etc/sudoers.

Start with:

whoami

Then:

id

Then:

sudo -l

If sudo itself is available but the command fails, test:

sudo id

Then check the exact command:

sudo command

If you receive a sudoers error, inspect the relevant configuration:

sudo visudo -c

This checks the sudoers configuration.

You can also inspect included files:

sudo ls -l /etc/sudoers.d/

A practical workflow is:

Who am I?
    |
    v
What groups am I in?
    |
    v
What does sudo allow?
    |
    v
Can sudo authenticate me?
    |
    v
Can I run the specific command?
    |
    v
Is the sudoers configuration valid?

---

Useful sudo Commands Cheat Sheet

Command	What it does
sudo command	Run a command with elevated privileges
sudo -l	List sudo permissions
sudo -v	Validate/refresh sudo credentials
sudo -k	Invalidate cached credentials
sudo -K	Remove cached credentials
sudo -u user command	Run a command as another user
sudo -iu user	Start a login shell as another user
sudo -i	Start a root login shell
sudo -s	Start a shell with elevated privileges
sudo -E command	Preserve environment variables when permitted
sudoedit file	Edit a file using sudo privileges
sudo visudo	Safely edit sudoers
sudo visudo -c	Validate sudoers configuration
sudo --version	Display sudo version

---

A Few sudo Habits Worth Keeping

After working with Linux servers for a while, a few habits can prevent a lot of trouble.

1. Check the command before pressing Enter

Especially with:

sudo rm

or:

sudo chmod

or:

sudo chown

A privileged typo can have a much larger blast radius.

2. Prefer specific sudo permissions

If someone only needs to restart one service, don’t automatically give them unrestricted root access.

3. Use absolute paths in sudoers rules

For example:

/usr/bin/systemctl

is preferable to an ambiguous executable name when writing restrictive policies.

4. Use visudo

Always validate sudo configuration before relying on it.

sudo visudo -c

5. Don’t stay in a root shell unnecessarily

If you only need one privileged command:

sudo command

is often clearer than:

sudo -i

followed by a series of commands.

---

Final Thoughts

sudo looks simple when you first encounter it:

sudo command

But underneath that command is a fairly powerful authorization system.

Understanding sudo means understanding more than how to become root. It means knowing:

• Who can run a command
• Which commands they can run
• Which user the command runs as
• Where the rule applies
• Whether authentication is required
• How the action is logged
• How to restrict privileges safely

For Linux administrators, sudo is one of those commands that’s easy to learn but worth understanding deeply.

The next time you type:

sudo

remember that you’re not simply asking Linux for “more permissions.”

You’re asking Linux to apply a specific authorization policy to a specific command.

And on a production server, that distinction matters.