Sudo and Root on Linux: Becoming Root and Granting Sudo Access

Root (UID 0) can do anything on a Linux system, which is exactly why you should not work as root by default. sudo lets a regular user run single commands with root privileges, asks for that user's own password, and logs every call. This post covers how to become root, how to give a user sudo rights, and the mistakes that lock people out.

Running commands as root

sudo apt update                 # one command as root
sudo -u postgres psql           # one command as another user
sudo -l                         # list what you may run

sudo asks for your password, not root's. After a successful prompt it caches the credentials for a few minutes (the timestamp_timeout setting), so the next commands go through without asking. sudo -k drops that cache immediately.

In bash, sudo !! reruns the previous command with sudo, which is handy after a "Permission denied".

Ubuntu 25.10 and later ship sudo-rs, a Rust reimplementation, as the default sudo. Everything in this post works the same way there.

Getting a root shell

When you have a series of admin tasks, a root shell is more practical than prefixing every line.

sudo -i     # login shell as root: root's environment, starts in /root
sudo -s     # shell as root, keeps most of your environment and current directory
su -        # switch to root with root's password, login shell

Prefer sudo -i over sudo su -. They end up in the same place, but sudo su - runs two privilege tools for no reason. Use su - (with the dash) only when sudo is not set up: without the dash you keep your own PATH and environment, which leads to odd behavior.

Exit the root shell with exit or Ctrl+D as soon as you are done. Long-lived root shells are how people run rm -rf in the wrong directory.

Why su says "Authentication failure" on Ubuntu

Ubuntu locks the root account by default: it has no password, so su cannot work. That is intended. Use sudo -i instead. You can set a root password with sudo passwd root, but there is rarely a good reason to, and it opens another account to password guessing if SSH allows it.

Debian depends on what you chose during install. If you set a root password, the installer does not add your user to the sudo group (and on minimal installs sudo may not be installed at all). Log in as root with su - and fix that as shown below.

Adding a user to sudoers

The clean way is group membership. The sudoers file on every major distro already grants full access to one group:

• Debian and Ubuntu: sudo
• RHEL, CentOS Stream, AlmaLinux, Rocky, Fedora: wheel

# Debian / Ubuntu
sudo usermod -aG sudo alice

# RHEL family
sudo usermod -aG wheel alice

The -a matters. usermod -G sudo alice without it replaces all of Alice's supplementary groups with just sudo.

Group changes apply to new login sessions. Alice has to log out and back in (or open a new SSH session) before sudo works for her. Check the result:

id alice
sudo -l -U alice

On Debian, if sudo itself is missing, install it first as root: apt install sudo.

Custom rules with visudo and sudoers.d

Never edit /etc/sudoers with a normal editor. A syntax error there breaks sudo for everyone, and if root has no password you have just locked yourself out of the machine. visudo checks syntax before saving.

Put your own rules in separate files under /etc/sudoers.d/ instead of changing the main file. Package upgrades will not touch them, and they are easy to manage with Ansible or similar tools.

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

# Let the deploy user restart one service without a password
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart my-app.service

# Full sudo for a user, password required
alice ALL=(ALL:ALL) ALL

The format is who where=(as_user:as_group) commands. Always use absolute paths for commands. A rule like NOPASSWD: /usr/bin/vim or /usr/bin/less is effectively full root, because both can spawn a shell. Shell scripts that the user can edit are the same problem.

A few details that catch people:

• File names in sudoers.d that contain a dot or end in ~ are ignored. deploy works, deploy.conf silently does nothing.
• Files should be mode 0440 and owned by root. visudo -f handles this for new files.
• Check everything with sudo visudo -c.
• Before closing your current session, open a second terminal and confirm sudo still works.

Common pitfalls

Redirection runs as you, not root.

sudo echo "vm.swappiness=10" > /etc/sysctl.d/99-swap.conf   # Permission denied
echo "vm.swappiness=10" | sudo tee /etc/sysctl.d/99-swap.conf
echo "10.0.0.5 db.internal" | sudo tee -a /etc/hosts        # append

The shell opens the file before sudo runs, with your permissions. tee runs under sudo and does the writing.

Editing files as root. sudoedit /etc/nginx/nginx.conf (same as sudo -e) copies the file to a temp location, opens it in your own editor with your config, and writes it back as root. Your editor never runs with root privileges.

Environment. sudo resets most environment variables and uses secure_path, so a tool in ~/.local/bin is not found under sudo. Use the full path or install it system-wide.

Audit trail. Every sudo call is logged: /var/log/auth.log on Ubuntu (on Debian only if rsyslog is installed, which Debian 12+ does not do by default), /var/log/secure on RHEL, or journalctl _COMM=sudo everywhere with systemd.

Quick reference

sudo cmd                          # run as root
sudo -u user cmd                  # run as another user
sudo -i                           # root login shell
su -                              # root shell with root's password
sudo -l                           # list your sudo rights
sudo -k                           # forget cached credentials
sudo usermod -aG sudo alice       # Debian/Ubuntu: grant sudo
sudo usermod -aG wheel alice      # RHEL family: grant sudo
sudo visudo -f /etc/sudoers.d/x   # custom rule, syntax-checked
sudo visudo -c                    # validate all sudoers files
sudoedit /etc/file                # edit a root-owned file safely
echo text | sudo tee /etc/file    # write to a root-owned file