Use sudo: run a command as root

sudo runs a single command with root privileges, without you having to log in as root. It is the basic move of Linux administration: you stay on your regular account, and you ask for a one-off privilege elevation when the command needs it. Here you will learn to run a privileged command, to open a temporary root shell, to read your rights with sudo -l and to get out of the two most frequent beginner errors.

This page covers the use of sudo. Writing the rules that decide who may do what is another job, covered in Configure sudoers and delegate rights.

What you will learn

• Understand why you should not work as root day to day
• Run a privileged command with sudo
• Open a temporary root shell with sudo -i and leave it
• Read your own rights with sudo -l
• Recognise the sudo (Debian) and wheel (Red Hat) groups

Why not work as root?

The root account (UID 0) has no safety net: the kernel refuses it nothing. A typo that would cause a mere permission error on your account becomes an irreversible destruction as root. The table below shows three commands everyone types one day, and what a misplaced space makes them do.

Command	Consequence as root
rm -rf /tmp/*	Deletes the contents of /tmp, the expected behaviour
rm -rf / tmp/* (extra space)	Deletes the whole system
chmod -R 777 /	Makes the whole system writable by everyone

Swipe to see more

Working with a regular account and sudo adds three useful brakes: you must type sudo explicitly, which forces you to name the dangerous action; you must enter your password; and every call leaves a named trace in the system logs. The third point matters as much as the other two: after an incident, it is what tells you who did what.

Golden rule

Stay on your regular account. Only call sudo on the commands that really need it, one by one.

How do you run a command with sudo?

The syntax fits in one word: prefix the command with sudo. The system then asks for your password, not root's, which you probably do not even have, since root often has no password at all.

sudo apt update

Check right away that the elevation happened, with the id command, which shows the effective identity of the process started:

id -un        # your account
sudo id -un   # the identity obtained through sudo

Output

bob
root

The second line shows root: the command passed to sudo does run with the identity of the superuser, while your shell itself stayed on your account.

Which commands need sudo?

A reflex settles in quickly: sudo is needed as soon as you write outside your home directory. In practice, that covers installing packages, changing configuration files in /etc, managing services and reading some logs.

sudo apt install tree        # Debian/Ubuntu
sudo dnf install tree        # Fedora/RHEL

sudo nano /etc/hostname      # system configuration file
sudo systemctl restart ssh   # managing a service
sudo journalctl -n 50        # system logs

On the other hand, reading a public file (cat /etc/passwd), listing a directory or working in your $HOME needs no privilege. Prefixing everything with sudo out of superstition is an anti-pattern: you end up with files owned by root in your own directory, which you can no longer change without... sudo.

The password is not asked every time

After a first successful authentication, sudo remembers your validation for a few minutes, per terminal. This delay (timestamp_timeout) depends on the distribution, which surprises people moving from one family to the other:

Distribution	Remembering delay
Debian / Ubuntu	15 minutes
RHEL / Rocky / Fedora (upstream value)	5 minutes

Swipe to see more

To read the value actually applied on your machine rather than assume it, ask sudo itself:

sudo sudo -V | grep -i "timestamp timeout"

Output on Ubuntu 24.04

Authentication timestamp timeout: 15.0 minutes

If you want to close the session before it expires, for example before leaving your desk, sudo -k forgets the authentication immediately. The next command will ask for the password again.

How do you open a temporary root shell?

When you chain ten privileged commands, prefixing each one with sudo becomes tedious. The temporary root shell answers that case: you become root for the length of a task, then you leave.

sudo -i

Output

root@server:~#

The prompt changes shape: the $ becomes #. It is the visual signal that every command typed here runs as root, with no safety net. Confirm if needed with whoami, which must answer root. To go back to your account, exit is enough.

Do not stay root

Leave the root shell as soon as the task is done. A root terminal forgotten in a tab is the classic cause of an rm -rf run in the wrong directory.

What is the difference between sudo -i and sudo -s?

Both options open a root shell, but they do not start from the same place, which explains a confusing behaviour: after sudo -s, you are root but still in your directory. Measured on Debian 13, Ubuntu 24.04 and AlmaLinux 10, $HOME is /root in both cases.

Command	Effect
sudo -i	Root login shell: reads root's profile and starts in /root
sudo -s	Root shell without login: stays in the current directory, without reading root's login profile

Swipe to see more

Pick sudo -i by default. It starts in a clean and predictable environment, identical to a real root login, which keeps you from running a destructive command in the wrong directory. sudo -s is still useful when the task is precisely about the files of the directory you are in.

How do you check your rights with sudo -l?

sudo -l answers a precise question: what am I allowed to do, me, on this machine? It is the first command to type on a server you discover, before finding out the hard way that a command is refused.

sudo -l

Output (account with every right)

Matching Defaults entries for bob on server:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty

User bob may run the following commands on server:
    (ALL : ALL) ALL

The line (ALL : ALL) ALL reads from left to right: every target identity, every target group, every command. In other words, full root access. On a well-kept server, you will rather see a limited list of allowed commands.

If your account has no right at all, sudo says so explicitly:

Output (account without sudo rights)

Sorry, user alice may not run sudo on server.

sudo -l only shows your rights

sudo -l lists your permissions, never those of other accounts. To audit another user's rights, you need sudo -lU <user>, detailed in Configure sudoers and delegate rights.

What are the sudo and wheel groups?

On a standard installation, you do not grant sudo rights account by account: you add the user to an administrators group already allowed in the configuration. The name of this group is the main divergence between distribution families.

Debian / Ubuntu

The group is called sudo:

# Check your own membership
groups | grep sudo

# Add alice to the administrators group
sudo usermod -aG sudo alice

# Check the result
id -nG alice

Red Hat / Fedora / Rocky

The group is called wheel:

# Check your own membership
groups | grep wheel

# Add alice to the administrators group
sudo usermod -aG wheel alice

# Check the result
id -nG alice

The id -nG alice command must now show sudo (or wheel) among her groups. Beware of the classic trap: group membership is read at login. As long as alice has not logged out and back in, her current shell ignores her new group and sudo keeps rejecting her.

Where is sudo configured?

The configuration lives in the /etc/sudoers file and in the files of the /etc/sudoers.d/ directory. That is where the rules deciding who can run which command and as which identity are written. You never open it with an ordinary editor: the visudo command locks the file and checks its syntax before saving, because a mistake in this file can make sudo unusable for everyone, including you.

As a beginner, you do not need to touch it: adding the account to the sudo or wheel group covers the common need. The day you must allow a team to restart a single service without handing it the whole of root, everything happens in these files, and that is the subject of Configure sudoers and delegate rights: rule syntax, aliases, NOPASSWD, drop-ins and audit.

Troubleshooting

Three messages come back again and again with beginners. They all have a simple cause, and none of them is solved by typing the command a second time harder. The fix almost always involves a group or a password.

Symptom	Likely cause	Fix
bob is not in the sudoers file	The account does not belong to the sudo/wheel group	Have it added to the group, then log in again
sudo: command not found	sudo package missing (minimal images, containers)	As root: apt install sudo or dnf install sudo
The password is refused	You are typing root's password	Type your user password
The password is asked again and again	The remembering delay has expired (15 min Debian, 5 min RHEL)	Normal behaviour, type it again
Nothing changes after usermod -aG	Groups are loaded at login	Log out and back in, check with id -nG

Swipe to see more

Key points

• Do not work as root day to day: elevate your privileges command by command.
• sudo <command> runs one command as root; check with sudo id -un.
• sudo -i opens a temporary root shell: the prompt goes from $ to #, and exit leaves it.
• sudo -l shows your rights, and only yours.
• Access goes through the sudo group (Debian) or wheel (Red Hat), effective after logging in again.
• The password stays remembered 15 minutes on Debian/Ubuntu, 5 minutes on RHEL; sudo -k forgets it at once.

Knowledge check

Check that the essentials of this guide stuck. The questions cover only what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

×

See in the glossary →