Run Administrative Commands Safely with sudo on Ubuntu

By the end of this guide, you will be able to run a single command as root, verify that it really received elevated privileges, and use a temporary root shell without enabling a separate root password. The examples target the Ubuntu setup described by the installed sudo_root(8) manual page. On this machine, the installed package is sudo 1.9.15p5-3ubuntu5.24.04.3.

Allow about 10 minutes. You need a local account that is already allowed to use sudo, an interactive terminal, and a command whose administrative effect you understand. The password prompt asks for your normal login password, not a root password.

Before you start: check your access

1. Check which accounts are currently in the local sudo group.

getent group sudo

On the reference system, the result includes andy:

sudo:x:27:andy

The group listing is useful context, but it does not prove that your current session can run every permitted command. Test the permission without prompting or changing anything:

sudo -n true

No output and exit status 0 means that sudo accepted the cached authorisation. A message saying a password is required means only that no cached credential is available. Run sudo true interactively if you are authorised and expect a prompt. A message saying your user is not in the sudoers file requires an administrator to change the policy.

Run one administrative command

1. Put sudo immediately before the command that needs root privileges.

For a harmless, observable test, ask root for its numeric user ID:

sudo id -u

After the password prompt, the expected output is:

0

Only the command after sudo is elevated. The shell that parses your command line is still your ordinary shell. That distinction matters for redirection. This does not give the shell permission to create the file:

sudo printf '%s\n' 'managed by root' > /root/example.txt

The > is handled by your shell before printf runs, so opening /root/example.txt can fail. Send the data through tee instead:

printf '%s\n' 'managed by root' | sudo tee /root/example.txt

sudo rm -- /root/example.txt

If a command changes a service, package database, configuration file or user account, read its local manual page first. Do not paste a command containing an unfamiliar path or a wildcard into a privileged shell.

Use a temporary root shell

1. Start a login shell as root only when several related commands genuinely need elevation.

sudo -i

Confirm the shell identity before doing work:

id -u
whoami

The output should contain 0 and root. The prompt may also change, but do not rely on its appearance. Type exit as soon as the administrative work is complete:

exit

sudo -i is broader than prefixing one command: every command entered before exit has root privileges. Keep the shell short-lived and re-check paths before commands that remove or replace data.

Add another administrator

1. Ask the new user to log out and back in, then add the existing account to the local sudo group.

Replace NEWUSER with the exact local username. This operation requires your own sudo access:

sudo adduser NEWUSER sudo

The command updates group membership. It does not turn on a root password. The new user normally needs a new login session before the group is visible. Verify the membership from that account with:

id -nG

Look for sudo in the output, then test with sudo -n true. If the change was accidental, remove the user from the group with:

sudo deluser NEWUSER sudo

Check the username before pressing Enter. Removing the wrong account can interrupt someone else's administration, while adding the wrong account grants full administrative access.

Do not enable a separate root password casually

The reference manual describes the root password as locked by default and recommends leaving that arrangement in place. Enabling it with sudo passwd root creates a second authentication route and makes shared root access harder to audit. The same manual describes editing sudo policy with visudo if sudo access is to be disabled, but changing both authentication and policy can strand a machine if no other administrator remains.

If you have just added a test user to the sudo group, undo that group change with sudo deluser NEWUSER sudo. Do not try to repair a broken sudoers policy by editing it with a normal text editor: visudo performs syntax checks before installing the result. Keep one known-good administrative session open while making policy changes, and test a second session before closing it.

Common failures and recovery

• Authentication failed: enter your login password carefully. A root password is not expected. Stop after repeated failures and check the account or keyboard layout.
• User is not allowed: ask an existing administrator to add the account to the intended policy. Adding a group entry by hand is not a substitute for understanding the site's sudoers configuration.
• Permission denied with redirection: move the write operation into an elevated process, such as tee, and inspect the target path first.
• Still root after the task: run exit until the root shell closes, then verify with id -u.
• Network-backed users cannot administer a recovery system: the manual warns that a broken NSS service can make imported users unavailable. Maintain a tested local administrative account before depending on network identity.

Done means

• sudo id -u returned 0.
• You used sudo -i only for a short, deliberate task and exited it.
• You treated shell redirection as separate from command elevation.
• Any new sudo-group membership is intentional and has been checked in a fresh session.
• You have not enabled a root password merely to avoid learning the sudo workflow.