sudo & the Root User

Every Linux server has one all-powerful account called root (the superuser, an account that can do absolutely anything on the system). Root can read any file, delete any file, change any setting, and even brick the machine. Because root is so dangerous, modern Linux practice is to almost never log in as root directly. Instead you log in as a normal user and use sudo (“superuser do”) to run single commands with elevated rights when you actually need them. This page explains why that matters and how to do it the right way on Ubuntu 22.04 / 24.04 LTS.

What is the root user?

Root is the account with user ID 0 (UID 0). The kernel treats UID 0 specially: it skips almost every permission check. That means root can overwrite system files, install software, stop services, manage other users, and read every user’s private data.

Every other account is a normal (unprivileged) user. Normal users can only touch their own files and a few shared areas. If a normal user tries to edit a protected system file, they get “Permission denied” — which is exactly the safety net you want.

You can see your own identity with the id command:

id

Output:

uid=1000(deploy) gid=1000(deploy) groups=1000(deploy),27(sudo)

Here the user deploy has UID 1000 (a normal user) and belongs to the sudo group — membership in that group is what gives them permission to run sudo.

Why logging in as root directly is dangerous

It is tempting to just log in as root so you never see “Permission denied” again. Don’t. Direct root use causes real problems:

• No undo and no safety net. A typo like rm -rf / var/log (note the accidental space) wipes the whole disk. As a normal user, the same command would mostly fail with permission errors.
• No audit trail. When everyone logs in as root, you cannot tell who ran a destructive command. With sudo, every elevated command is logged with the real person’s username.
• Bigger blast radius for attacks. If an attacker steals your password while you are root, they instantly own the server. If they steal a normal user’s password, they still have to get past sudo.
• Bad habits. Running your editor, browser tests, or build scripts as root means any bug in those tools runs with full power.

Security warning: Treat “I’ll just use root, it’s faster” as a red flag. The few seconds sudo saves are not worth the day you spend rebuilding a server you accidentally destroyed.

How sudo works

sudo lets a permitted normal user run a single command as root (or as another user). It gives you temporary elevated rights, asks for your own password (not root’s), and records what you ran. After you authenticate, sudo remembers you for a short window (15 minutes by default) so you don’t retype your password for every command.

Run one command as root

Put sudo in front of any command that needs root rights:

sudo apt update

Output:

[sudo] password for deploy:
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Reading package lists... Done

If you forget sudo on a command that needs it, you get a clear error:

apt install nginx

Output:

E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)
E: Unable to acquire the dpkg frontend lock, are you root?

Open a root shell with sudo -i

Sometimes you have several admin tasks in a row and prefixing every command with sudo is tedious. sudo -i starts an interactive root login shell — it behaves like you logged in as root, loading root’s environment and home directory.

sudo -i

Output:

root@web-01:~#

The # at the end of the prompt (instead of $) is the universal sign that you are now root. Type exit to drop back to your normal user as soon as you’re done.

sudo -i vs sudo -s vs su

These look similar but behave differently. Choose based on what environment you want.

Command	What it does	Loads target user’s environment?	When to use
sudo <cmd>	Run one command as root	No	The default — best for almost everything
sudo -i	Full root login shell	Yes (root’s $HOME, profile)	Several admin tasks in a row
sudo -s	Root shell, keep your environment	No (keeps your $HOME, vars)	Quick root shell that keeps your settings
su -	Switch to root using root’s password	Yes	Legacy; needs root password (often disabled)

Tip: Prefer sudo -i over su -. On Ubuntu the root password is locked by default, so su - won’t even work — and sudo -i keeps the audit trail tied to your account.

The audit trail

Every sudo command is logged. On Ubuntu you read it through the systemd journal (the central log database managed by journalctl):

sudo journalctl -t sudo --no-pager | tail -n 3

Output:

Jun 15 10:42:01 web-01 sudo[2210]: deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/usr/bin/apt update
Jun 15 10:43:18 web-01 sudo[2231]: deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/usr/bin/systemctl restart nginx

You can see exactly who ran what, when, and from where. This is impossible if everyone shares the root login.

Best practice: disable root SSH login

By default a fresh cloud server may allow logging in over SSH (Secure Shell, the encrypted protocol you use to reach a remote server) directly as root. Attackers constantly scan the internet trying root with common passwords. Closing that door is one of the highest-value hardening steps.

First make sure your normal user has sudo and you can log in as them. Then edit the SSH server config:

sudo nano /etc/ssh/sshd_config

Find or add this line:

PermitRootLogin no

Save the file, test the config, and restart SSH:

sudo sshd -t
sudo systemctl restart ssh

Output:

(no output means the config is valid)

Warning: Before you log out, open a second SSH session as your normal user to confirm you can still get in and run sudo. If you lock yourself out without verifying, you may need console access from your hosting provider to recover.

Best Practices

• Never log in as root for daily work. Log in as a normal user and reach for sudo only when a command actually needs it.
• Use sudo <command> by default; only open a root shell with sudo -i when you have a real batch of admin tasks, and exit it immediately after.
• Keep the root password locked (Ubuntu’s default) and rely on sudo so every action is tied to a named person.
• Set PermitRootLogin no in /etc/ssh/sshd_config and prefer SSH key authentication over passwords.
• Review the audit trail with journalctl -t sudo after incidents or unexpected changes.
• Grant sudo sparingly — add users to the sudo group only when they truly need admin rights, and remove it when they no longer do.

Related Topics

• Users & Groups
• Managing the sudoers File
• Viewing Logs with journalctl
• apt Package Management
• systemd Services