Knowing how to add a new user to sudoers on Ubuntu keeps your administration workflow flexible without sacrificing security. Ubuntu relies on sudo for privileged actions, so assigning the right users to the sudo group lets teams share responsibilities while keeping a clear audit trail.
Whether you are onboarding a new administrator, preparing an automation account for configuration management, or granting temporary break-glass access during an outage, the process follows the same smart pattern: create the account, grant the sudo group, verify the permissions, and tighten the policy when needed. This workflow applies to every supported Ubuntu desktop and server release.
Understand How sudo Grants Administrative Access
If you are new to sudo, think of it as a controlled gateway that lets trusted users run privileged commands without logging in as root. Ubuntu ties that gateway to the sudo group and reads fine-grained policies from the sudoers files, so you always know who can run what.
sudo usermod -aG sudo <username>sudoelevates the following command while logging the action for auditing.usermodedits an existing account instead of recreating it from scratch.-aGappends the user to one or more supplementary groups without overwriting current memberships.sudogroup is the built-in Ubuntu group that confers administrator rights.<username>is the account you want to promote; swap it for the real user.
At its simplest, running sudo usermod -aG sudo newadmin places the newadmin account in the sudo group so the user can run administrative commands after their next login.
| Task | Options / Commands | What They Do |
|---|---|---|
| Create a user | sudo adduser newadmin | Guides you through password and profile prompts in one command. |
| Grant sudo access | sudo usermod -aG sudo newadmin | Adds the account to the sudo group without touching other memberships. |
| Confirm privileges | groups newadminsudo -l -U newadmin | Prints the user’s group list and enumerates sudo rules they inherit. |
| Harden policies | sudo visudo -f /etc/sudoers.d/newadmin | Creates user-specific sudo rules that stay isolated from the main file. |
| Revoke access | sudo gpasswd -d newadmin sudo | Removes the user from the sudo group the next time they log in. |
Prerequisites
You need an existing account that already has sudo privileges because Ubuntu ships with the root account locked. Make sure you can run sudo commands before you start.
- Any supported Ubuntu desktop or server release with shell access
- An existing sudo-enabled account to bootstrap new users
- Optional: familiarity with text editors like nano or vim for sudoers configuration
If you prefer to work in a different editor than nano when editing sudoers later, set it ahead of time with sudo update-alternatives --config editor.
Step 1: Create the new user account
Start by creating the user with adduser, which walks you through the password and profile prompts in one pass. Replace newadmin with your desired username.
sudo adduser newadminPress Enter for any fields you do not need, then confirm with Y to finish. Once complete, the account is now present in /etc/passwd.
Step 2: Add the user to the sudo group
Ubuntu grants sudo privileges through membership in the sudo group. Append the new user to that group with usermod, which keeps existing group memberships intact.
sudo usermod -aG sudo newadminAlternative Methods to Grant sudo Access
Ubuntu accepts a few other paths if you have existing scripts or personal preferences. Each of the following workflows ends with the user inside the sudo group, so pick the variant that matches your automation style.
Method 1: Chain adduser Commands
When you are already running adduser interactively, immediately follow it with the sudo group assignment. This keeps prompts in the same terminal session and mirrors the workflow shown in the screenshot.
sudo adduser newadmin
sudo adduser newadmin sudoThe first command creates the account, while the second reuses the same helper to append the user to supplementary groups. Afterward, confirm success with id newadmin.
Method 2: Use gpasswd in Scripts
Configuration management tools often rely on gpasswd because it appends users to groups without touching anything else. The command exits cleanly when the membership already exists, so it is safe to rerun.
sudo gpasswd -a newadmin sudoPair this with groups newadmin or getent group sudo inside your automation to verify that the account now inherits sudo privileges.
Method 3: Low-Level useradd Workflow
Minimal images sometimes ship without the friendlier helpers. In those cases, build the account with useradd, assign the login shell, and manage passwords manually before granting sudo.
sudo useradd -m -s /bin/bash newadmin
sudo passwd newadmin
sudo usermod -aG sudo newadminThis sequence mirrors what adduser does under the hood but gives you precise control when building cloud images or container templates.
Regardless of the command chain you choose, the target user must start a new session before sudo group membership applies to interactive shells.
If you need to test the change immediately, switch into the account with su - newadmin or open a fresh SSH session as that user so the new group list loads. Commands such as newgrp only change the primary group of your current shell, so they will not refresh another user’s membership.
The screenshot below shows this workflow in action: after switching to root with su, the administrator runs adduser josh and steps through the password prompts before assigning sudo privileges.
adduser walks you through password prompts, as shown while creating the josh account from a root shell.Step 3: Verify sudo capabilities
Before handing the account to someone else, check that the user received group membership. The groups command prints all groups for the user, and sudo -l -U reveals the sudo rules they inherit.
groups newadmin
sudo -l -U newadminAlternatively, you can use getent group sudo to list every member of the sudo group at once, or run id newadmin to see the user’s UID alongside all group memberships with their corresponding GIDs.
getent group sudo
id newadminFor a live test, switch into the account and run a harmless privileged command. Subsequently, the prompt for the user password confirms that sudo is working.
su - newadmin
sudo whoamiThe expected output is root. However, if sudo still fails, log out and back in so the session picks up the new group membership.
Optional: Add fine-grained sudo rules with visudo
Most teams only need group-based access, but you can craft custom sudo policies for individual users when specific requirements arise.
Always edit sudoers with
visudoso syntax errors are caught before the file saves.If you need passwordless sudo for automation, scope the rule narrowly with
NOPASSWD:and keep it limited to trusted scripts.
sudo visudo -f /etc/sudoers.d/newadminAdd rules in a dedicated file under /etc/sudoers.d/ so the primary sudoers configuration stays intact. Grant full sudo access while keeping the audit trail with a user-specific entry like the following:
newadmin ALL=(ALL:ALL) ALLIf you later need a different command set for the same user, create another file under /etc/sudoers.d/ with only the required entries so changes remain modular and easy to audit.
Restrict sudo to Specific Commands
When a user needs to restart a service or run a maintenance script but should not have full system access, limit the sudoers entry to specific commands. This approach follows the principle of least privilege and reduces the blast radius if the account gets compromised.
webadmin ALL=(ALL:ALL) /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginxUse absolute paths when specifying commands so a malicious user cannot place a fake binary earlier in the PATH and trick sudo into running it. Additionally, avoid wildcards or shell expansion characters in sudoers rules because they can be exploited to gain unintended access.
For passwordless automation of safe, read-only commands, append NOPASSWD: before the command list. However, limit this to commands that cannot modify system state or access sensitive data.
monitor ALL=(ALL:ALL) NOPASSWD: /usr/bin/systemctl status nginx, /usr/bin/journalctl -u nginxList every allowed command explicitly, even when they look repetitive, so attackers cannot abuse wildcards to run unexpected binaries.
Optional: Remove sudo access later
When a user no longer needs administrator rights, drop them from the sudo group. The change takes effect the next time they log in.
sudo gpasswd -d newadmin sudoFollow up with groups newadmin to confirm the removal. Additionally, clean up any custom sudoers entries you created for the user.
Optional: Prepare a Break-Glass Recovery Path
Sudo covers almost every administrative task, yet you still need a contingency plan for the rare moment when sudo itself refuses to run. Ubuntu ships with the root account locked, so su - fails until you intentionally set a root password or open a rescue console.
sudo passwd root
sudo passwd -l rootSet a temporary root password with the first command only when you need break-glass access, then lock it again with sudo passwd -l root after the emergency ends. Store those credentials in your password vault rather than chat or email threads.
Test your cloud, hypervisor, or BMC console access ahead of time. Knowing how to reach a serial console or rescue environment prevents panic when sudo is unavailable.
Finally, keep at least one additional administrator account with sudo privileges and document how to reach out-of-band console access. Practicing these recovery steps means you can regain control quickly if someone misconfigures sudoers or removes their own privileges.
Understanding sudo vs su
Both sudo and su let you run commands with elevated privileges, but they handle authentication and auditing differently. Understanding when to use each keeps your workflow secure and accountable.
When you run sudo command, the system asks for your own password and executes that single command as root while logging the action to /var/log/auth.log. This approach lets multiple administrators perform privileged tasks without sharing the root password, and every action gets attributed to the person who ran it. Once the command finishes, your shell returns to normal user privileges.
In contrast, su - switches your entire shell session to the root user and asks for the root password, not yours. Ubuntu locks that password by default, so su only succeeds after you intentionally enable the root account as part of your break-glass plan. You stay in that elevated session until you explicitly type exit, and every command you run appears in logs as coming from root rather than your original account. This makes it harder to trace who did what when multiple people know the root password.
Use sudo for day-to-day administrative tasks, especially in team environments where accountability matters. Reserve su for troubleshooting scenarios where sudo itself is broken, or when you need to test how a service behaves under a different user account with su - serviceuser.
Best Practices for Managing sudo Access
Granting sudo privileges carries security implications, so follow these patterns to keep your systems locked down while maintaining operational flexibility.
Start with the principle of least privilege: only grant sudo access to users who genuinely need it, and limit their permissions to the smallest command set that lets them do their job. A web developer who needs to restart nginx does not need full root access to install kernel modules or modify firewall rules. When you create sudoers entries, use absolute command paths like /usr/bin/systemctl instead of bare command names so a compromised user cannot inject a malicious binary earlier in the PATH.
Avoid wildcards in sudoers rules unless you have tested every edge case. A rule like user ALL=(ALL:ALL) /usr/bin/* looks convenient but grants access to every binary in that directory, including ones you did not anticipate. Similarly, shell metacharacters in command arguments can be exploited to escape the intended restriction and run arbitrary code.
Use NOPASSWD: sparingly and only for commands that cannot cause damage. Status checks, log viewers, and read-only monitoring tools are usually safe candidates. However, anything that modifies system state, installs packages, or accesses sensitive files should always require password confirmation so you catch mistakes before they happen.
Regularly audit your sudoers configuration with sudo -l to see what permissions your account has, and review /etc/sudoers.d/ for entries that no longer serve a purpose. Furthermore, when someone leaves the team or changes roles, revoke their sudo access immediately and remove any custom sudoers files you created for them. This housekeeping prevents privilege creep and keeps the attack surface small.
Conclusion
Adding a new user to sudoers on Ubuntu is a quick workflow once you understand how the sudo group and sudoers policies work together. By creating the account, granting the right group membership, verifying the access, and reviewing the entry when roles change, you maintain secure administrative access without unnecessary complexity. This approach ensures trusted team members can perform privileged operations while preserving the audit trail that makes sudo valuable.