Linux sudo, sudoers and visudo Tutorial (plus PAM Basics) with Examples

By Ravindra Bagale, trainer · LinkedIn · Last updated: 25 October 2026

1. An everyday example: the office master key

Why do we need this?

At a Hinjewadi office, only the admin manager has the master key. Instead of giving copies to everyone, the guard keeps it. Staff who are on the guard's list can ask for it for one job, sign the register, and give it back. The list says Nikhil can open only the server room, while Meera can open every room. At the gate, a security system checks ID cards, then fingerprints, then the time of day.

What is it?

Master key = root. Guard = sudo. Guard's list = /etc/sudoers. Signing the register = the sudo log. Nikhil only the server room = a rule for one command. Gate checks one after another = PAM modules in a stack.

How to do it (step by step)

2. sudo: run one command as root

Why do we need this?

Installing packages, restarting services and editing /etc need root. sudo gives that power for one command and records it.

What is it?

sudo COMMAND runs it as root after asking your password. The password is cached for a few minutes. sudo !! repeats the last command with sudo. -k forgets the cached password. -v refreshes it.

How to do it (step by step)

1. Restart a service.

sudo systemctl restart nginx

Output:

[sudo] password for ravi:

What it means: You type your own password, not root's.

2. Forgot sudo? Repeat with it.

dnf install -y htop; sudo !!

Output:

Error: This command has to be run with superuser privileges
...
Complete!

What it means: !! is the previous command.

3. Redirect into a root file (the right way).

echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swap.conf

Output:

vm.swappiness=10

What it means: sudo echo x > file fails because the shell does the > as you.

4. Forget the cached password.

sudo -k && sudo -n true

Output:

sudo: a password is required

What it means: -n never asks; good for scripts.

3. sudo -u and sudo -i: act as another user

Why do we need this?

You need to run a command as the app user (postgres, deploy) or get a full root shell for a long fix.

What is it?

sudo -u USER CMD runs as that user. sudo -i opens a root login shell (root's environment). sudo -iu USER opens a login shell as USER. sudo -s opens a shell but keeps your environment. sudo -E keeps your environment variables (if allowed).

How to do it (step by step)

1. Run psql as postgres.

sudo -u postgres psql -c 'select version();'

Output:

 PostgreSQL 16.4 on x86_64

What it means: No need to know the postgres password.

2. Open a root shell.

sudo -i && whoami

Output:

root

What it means: Type exit as soon as you finish.

3. Become the deploy user.

sudo -iu deploy && pwd

Output:

/home/deploy

What it means: Test exactly what the deploy user sees.

4. sudo -l: what am I allowed to run?

Why do we need this?

Before trying, or while debugging 'not allowed', see your rules.

What is it?

sudo -l lists your rules. sudo -l -U USER (root) lists another user's. sudo -ll gives a long format.

How to do it (step by step)

1. Your rules.

sudo -l

Output:

User ravi may run the following commands on web1:
    (ALL) ALL

What it means: ravi can run everything as anyone.

2. A limited user.

sudo -l -U nikhil

Output:

User nikhil may run the following commands on web1:
    (root) NOPASSWD: /usr/bin/systemctl restart nginx

What it means: Only one command, no password.

3. A user with no rights.

sudo -l -U guest

Output:

User guest is not allowed to run sudo on web1.

What it means: Clear answer for audits.

5. The sudoers file: rule syntax

Why do we need this?

To give the right power to the right person, you must read and write sudoers rules.

What is it?

A rule is WHO WHERE=(AS_WHOM) COMMANDS, for example ravi ALL=(ALL) ALL. %wheel means the wheel group. Commands need full paths. Tags like NOPASSWD: go before the commands. Lines starting with # are comments, but #include and @includedir are directives. Defaults lines change behaviour.

How to do it (step by step)

1. The admin group line.

sudo grep -E '^%(wheel|sudo)' /etc/sudoers

Output:

%wheel  ALL=(ALL)       ALL

What it means: Everyone in wheel gets full sudo.

2. Find full paths for rules.

command -v systemctl journalctl

Output:

/usr/bin/systemctl
/usr/bin/journalctl

What it means: Rules must use these exact paths.

3. Show the include line.

sudo grep -n includedir /etc/sudoers

Output:

120:#includedir /etc/sudoers.d

What it means: Not a comment: it loads files from that folder.

6. visudo: edit sudoers safely

Why do we need this?

One typo in /etc/sudoers can break sudo for everyone, and then you cannot fix it without root.

What is it?

visudo locks the file, opens it in an editor and checks the syntax before saving. visudo -f FILE edits a drop-in file. visudo -c checks all files. EDITOR=nano visudo picks the editor.

How to do it (step by step)

1. Edit with nano.

sudo EDITOR=nano visudo

Output:

(opens the editor)

What it means: Saves only if the syntax is valid.

2. What a typo looks like.

sudo visudo -c

Output:

/etc/sudoers.d/90-nikhil:1:30: syntax error
nikhil ALL=(root) NOPASSWD /usr/bin/systemctl

What it means: Missing colon after NOPASSWD.

3. All files OK.

sudo visudo -c

Output:

/etc/sudoers: parsed OK
/etc/sudoers.d/90-nikhil: parsed OK

What it means: Safe to log out now.

7. /etc/sudoers.d: drop-in rule files

Why do we need this?

Editing the main file by hand or by automation is risky. Small files per team are easy to add, review and remove.

What is it?

Put one file per purpose in /etc/sudoers.d/. Permissions must be 0440 and owner root. File names with a dot or ending in ~ are ignored. Always check with visudo -cf.

How to do it (step by step)

1. Give nikhil one restart command.

echo 'nikhil ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx' | sudo tee /etc/sudoers.d/90-nikhil

Output:

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

What it means: Only that exact command.

2. Fix permissions and check.

sudo chmod 0440 /etc/sudoers.d/90-nikhil && sudo visudo -cf /etc/sudoers.d/90-nikhil

Output:

/etc/sudoers.d/90-nikhil: parsed OK

What it means: Wrong permissions make sudo complain.

3. Test as nikhil.

sudo -u nikhil sudo -n systemctl restart nginx; sudo -u nikhil sudo -n systemctl stop nginx

Output:

(first works)
Sorry, user nikhil is not allowed to execute '/usr/bin/systemctl stop nginx' as root on web1.

What it means: Restart allowed, stop blocked.

4. Remove the access.

sudo rm /etc/sudoers.d/90-nikhil

Output:

(no output)

What it means: Rules are gone right away.

8. NOPASSWD, aliases and Defaults

Why do we need this?

CI jobs cannot type passwords, and many similar rules become messy. Aliases and Defaults keep rules short and safe.

What is it?

NOPASSWD: skips the password (limit it to exact commands). User_Alias, Cmnd_Alias, Host_Alias group names. Defaults set options: timestamp_timeout, logfile, requiretty, secure_path, env_keep. Never give NOPASSWD: ALL to a shared account, and avoid allowing editors, shells or tar (they can open a root shell).

How to do it (step by step)

1. A command alias for a team.

sudo tee /etc/sudoers.d/50-web <<'X'
Cmnd_Alias WEB = /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx, /usr/bin/journalctl -u nginx
%webops ALL=(root) WEB
X

Output:

(file written)

What it means: Everyone in webops gets those 3 commands.

2. CI deploy without a password.

echo 'deploy ALL=(root) NOPASSWD: /usr/local/bin/deploy.sh' | sudo tee /etc/sudoers.d/60-deploy

Output:

deploy ALL=(root) NOPASSWD: /usr/local/bin/deploy.sh

What it means: Make deploy.sh owned by root and not writable by deploy.

3. Cache the password for 2 minutes.

echo 'Defaults timestamp_timeout=2' | sudo tee /etc/sudoers.d/10-defaults

Output:

Defaults timestamp_timeout=2

What it means: 0 asks every time.

4. A separate sudo log file.

echo 'Defaults logfile=/var/log/sudo.log' | sudo tee -a /etc/sudoers.d/10-defaults && sudo visudo -c | tail -1

Output:

/etc/sudoers.d/10-defaults: parsed OK

What it means: Easy to ship to a SIEM.

9. sudo logs: who ran what

Why do we need this?

After an incident you must know who ran which command as root, and when.

What is it?

Every sudo use is logged with user, folder and command. RHEL family: /var/log/secure. Debian/Ubuntu: /var/log/auth.log. Everywhere with systemd: journalctl _COMM=sudo. Failed attempts say 'incorrect password attempts' or 'NOT in sudoers'.

How to do it (step by step)

1. Today's sudo commands.

sudo journalctl _COMM=sudo --since today | grep COMMAND | tail -2

Output:

ravi : TTY=pts/0 ; PWD=/home/ravi ; USER=root ; COMMAND=/usr/bin/systemctl restart nginx
priya : TTY=pts/1 ; PWD=/etc ; USER=root ; COMMAND=/usr/bin/vim nginx.conf

What it means: Who, where, as whom and what.

2. Failed sudo tries on Ubuntu.

sudo grep -E 'incorrect password|NOT in sudoers' /var/log/auth.log | tail -1

Output:

guest : user NOT in sudoers ; TTY=pts/2 ; PWD=/home/guest ; USER=root ; COMMAND=/bin/bash

What it means: Someone without rights tried to get a root shell.

3. Count sudo use per user.

sudo journalctl _COMM=sudo --since '7 days ago' | grep -o '^.*sudo\[[0-9]*\]: *[a-z]*' | awk '{print $NF}' | sort | uniq -c

Output:

  42 ravi
   7 priya

What it means: Good for a weekly review.

10. su vs sudo

Why do we need this?

Both give root, but they work very differently for safety and audit.

What is it?

su asks the TARGET user's password (root's), and gives a full shell, so logs only show 'su to root'. sudo asks YOUR password, can be limited per command, and logs each command. Most clouds (Ubuntu, Amazon Linux) lock the root password, so use sudo -i instead of su.

How to do it (step by step)

1. su to root on a cloud VM.

su -

Output:

Password:
su: Authentication failure

What it means: root has no password set.

2. The sudo way.

sudo -i

Output:

[root@web1 ~]#

What it means: Uses your password and is logged.

11. PAM: how Linux checks logins

Why do we need this?

Password rules, account lockout after failed tries, 2FA and home folder creation are all set in PAM, not in each program.

What is it?

Each service has a file in /etc/pam.d/ (sudo, sshd, login, su). Lines are TYPE CONTROL MODULE args. Types: auth (who are you), account (allowed now?), password (changing it), session (setup on login). Controls: required, requisite, sufficient, optional, include. Order matters. RHEL uses authselect to manage these files; Ubuntu uses pam-auth-update.

How to do it (step by step)

1. See the sudo PAM stack.

cat /etc/pam.d/sudo

Output:

auth       include      system-auth
account    include      system-auth
password   include      system-auth
session    include      system-auth

What it means: sudo reuses the common system-auth stack.

2. Where wheel is enforced for su.

grep pam_wheel /etc/pam.d/su

Output:

#auth  required  pam_wheel.so use_uid

What it means: Uncomment to allow su only for wheel members.

3. Check the active profile (RHEL).

authselect current

Output:

Profile ID: sssd
Enabled features:
- with-faillock

What it means: faillock is on.

12. pam_faillock and faillock: lock after failed tries

Why do we need this?

Bots guess passwords. Locking an account for a few minutes after 5 failures stops them, but you must know how to unlock a real user.

What is it?

pam_faillock counts failures. Settings in /etc/security/faillock.conf: deny=5, unlock_time=900. faillock --user NAME shows failures, --reset clears them. Older systems used pam_tally2.

How to do it (step by step)

1. See the policy.

grep -E '^(deny|unlock_time)' /etc/security/faillock.conf

Output:

deny = 5
unlock_time = 900

What it means: 5 tries, then 15 minutes locked.

2. See failures.

sudo faillock --user priya

Output:

priya:
When                Type  Source          Valid
2026-10-25 10:41:02 RHOST 103.21.5.9      V

What it means: Valid failures count toward the lock.

3. Unlock now.

sudo faillock --user priya --reset

Output:

(no output)

What it means: She can log in again.

13. pam_pwquality: strong password rules

Why do we need this?

Auditors ask for minimum length and mixed characters. PAM enforces it when users change passwords.

What is it?

/etc/security/pwquality.conf: minlen=12, dcredit=-1 (one digit), ucredit=-1, lcredit=-1, ocredit=-1, retry=3. pwscore tests a password.

How to do it (step by step)

1. Set a policy.

printf 'minlen = 12\ndcredit = -1\nucredit = -1\n' | sudo tee -a /etc/security/pwquality.conf

Output:

minlen = 12
dcredit = -1
ucredit = -1

What it means: At least 12 chars, one digit, one capital.

2. A weak password is refused.

passwd

Output:

New password: ****
BAD PASSWORD: The password is shorter than 12 characters

What it means: PAM checked it before saving.

3. Score a password.

echo 'Pune@Rain2026!' | pwscore

Output:

82

What it means: Higher is stronger.

14. Real examples from many industries

Why do we need this?

The same Linux skill shows up in every kind of company. Seeing it in many places helps you remember it.

What is it?

Each row is a made-up team. It shows who uses this and how.

How to do it (step by step)

15. Common errors and how to fix them

Why do we need this?

Everyone hits these errors. Knowing the cause saves hours.

What is it?

Read the exact message first. Then match it to a row below.

How to do it (step by step)

16. Troubleshooting step by step

Why do we need this?

When sudo refuses, check the rule, the file syntax and the PAM side, in that order.

What is it?

Go top to bottom. Stop at the first step that shows the problem.

How to do it (step by step)

1. Which user and groups am I?

id

2. What rules apply to me?

sudo -l

3. Are all sudoers files valid?

sudo visudo -c

4. Are drop-in permissions right?

ls -l /etc/sudoers.d/

5. Is the account locked by PAM?

sudo faillock --user $USER

6. Read the log for the exact reason.

sudo journalctl _COMM=sudo -n 20

17. Lab 1: Least-privilege sudo for an on-call engineer

Why do we need this?

Create a user who can only restart and read logs of one service, test it, then remove it.

What is it?

A full hands-on lab. Run every step on a test Linux machine (an EC2 instance, a VM, or WSL).

How to do it (step by step)

1. Create the user and group.

sudo groupadd webops && sudo useradd -m -G webops oncall1 && id oncall1

Output:

uid=1005(oncall1) gid=1005(oncall1) groups=1005(oncall1),3002(webops)

2. Write the rule with an alias.

sudo tee /etc/sudoers.d/50-webops <<'X'
Cmnd_Alias WEB = /usr/bin/systemctl restart nginx, /usr/bin/journalctl -u nginx
%webops ALL=(root) NOPASSWD: WEB
X
sudo chmod 0440 /etc/sudoers.d/50-webops

Output:

(file written)

3. Check syntax.

sudo visudo -cf /etc/sudoers.d/50-webops

Output:

/etc/sudoers.d/50-webops: parsed OK

4. List and test the rule.

sudo -l -U oncall1 && sudo -u oncall1 sudo -n systemctl stop nginx

Output:

(root) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/journalctl -u nginx
Sorry, user oncall1 is not allowed to execute '/usr/bin/systemctl stop nginx' as root on web1.

5. Find it in the log and clean up.

sudo journalctl _COMM=sudo -n 3 | grep oncall1; sudo rm /etc/sudoers.d/50-webops; sudo userdel -r oncall1

Output:

oncall1 : command not allowed ; TTY=pts/0 ; PWD=/home/ravi ; USER=root ; COMMAND=/usr/bin/systemctl stop nginx

18. Lab 2: Lockout policy with pam_faillock

Why do we need this?

See failures counted, lock a test account, and unlock it.

What is it?

A full hands-on lab. Run every step on a test Linux machine (an EC2 instance, a VM, or WSL).

How to do it (step by step)

1. Create a test user with a password.

sudo useradd -m locktest && echo 'locktest:Lab@2026pass' | sudo chpasswd

Output:

(no output)

2. Check the policy.

grep -E '^(deny|unlock_time)' /etc/security/faillock.conf || echo defaults

Output:

deny = 5
unlock_time = 900

3. Fail the password a few times.

for i in 1 2 3; do echo wrong | su - locktest -c true 2>&1 | tail -1; done

Output:

su: Authentication failure
su: Authentication failure
su: Authentication failure

4. See the count.

sudo faillock --user locktest

Output:

locktest:
When Type Source Valid
2026-10-25 11:02:10 TTY pts/0 V
... (3 lines)

5. Reset and clean up.

sudo faillock --user locktest --reset && sudo userdel -r locktest

Output:

(no output)

19. Frequently asked questions

20. Interview questions and answers

Beginner level

Mid level level

Senior level

21. Related chapters

• Linux Ops Refresh for DevOps
• Bash Scripting for Automation
• Linux grep and find Commands with Examples
• How to Set Up Passwordless SSH Between Linux Servers

Revision, comparison and interview cards

Revise this lesson in a few minutes. Save the cards on your phone or download them as PNG files. The QR code on each card opens this lesson.

More cards: Ravi Sir's Cards.