How to Add a User to Sudoers on Linux (Safely and Correctly)

Giving a user sudo access on Linux lets them run commands with administrator (root) privileges. That’s powerful — and dangerous if you’re not careful. This guide walks through what “sudoers” actually means, how it works, and several ways to add a user to sudoers on popular Linux distributions.

You’ll see where the steps differ between systems like Ubuntu, Debian, CentOS, Fedora, and others, and what choices you’ll need to make based on your own setup.

What Is “sudo” and the sudoers File?

On most Linux systems, you don’t log in as root directly. Instead, you:

• Log in as a regular user
• Use the sudo command to temporarily run specific commands with root privileges

Example:

sudo apt update sudo systemctl restart nginx 

Who is allowed to use sudo — and what they’re allowed to do with it — is controlled by:

• The sudoers file: usually /etc/sudoers
• Optional extra config files in /etc/sudoers.d/

These files define:

• Which users and groups can use sudo
• Whether they need a password
• Which commands they can run

Because mistakes in these files can lock you out of admin access, they’re edited with a special tool called visudo, which checks for syntax errors before saving.

Common Ways to Give a User sudo Access

There are two main approaches:

1. Add the user to a sudo-enabled group (most common and easiest)
2. Give the user specific sudo permissions in sudoers (more fine-grained)

Which one you should use depends on your Linux distribution and how tightly you want to control permissions.

1. Using a sudo Group (Ubuntu, Debian, Linux Mint, etc.)

On many Debian-based systems, members of the sudo group are allowed to use sudo.

To check this, look for a line like this in /etc/sudoers:

%sudo ALL=(ALL:ALL) ALL 

That means: “Users in the sudo group can run any command as any user, using sudo.”

Step-by-step: Add a user to the sudo group

You need root or existing sudo access to do this.

On Ubuntu / Debian / Mint and similar:

sudo usermod -aG sudo username 

Replace username with the actual account name.

• -aG = “append to these groups” (don’t remove existing ones)
• sudo = the group that has sudo rights

Log out and log back in for the new group membership to take effect, then test:

sudo whoami 

If it prints root, the user now has sudo access.

2. Using the wheel Group (CentOS, RHEL, Fedora, Rocky, Alma, etc.)

On many Red Hat-based systems, the wheel group is used for sudo (or su) access.

Look for a line like this in /etc/sudoers:

%wheel ALL=(ALL) ALL 

That gives full sudo to users in the wheel group.

Add user to the wheel group:

sudo usermod -aG wheel username 

On some systems, root access via su is tied to wheel. On others, sudo is configured too. To confirm, check sudoers (with visudo — covered below).

3. Giving a Single User sudo via the sudoers File

Sometimes you don’t want to rely on a group at all. Instead, you give just one user sudo privileges by adding a line for them in sudoers or a file under /etc/sudoers.d/.

Important: Always use visudo

visudo:

• Opens the sudoers file in a text editor
• Checks for syntax errors before saving
• Refuses to save a broken configuration

If you edit /etc/sudoers directly (for example, with nano or vim without visudo) and make a typo, you can break sudo for everyone — including yourself.

To edit the main sudoers file:

sudo visudo 

To edit or create a file under /etc/sudoers.d/:

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

Example: Full sudo access for one user

Add this line (in the main file or a file in /etc/sudoers.d/):

username ALL=(ALL:ALL) ALL 

Meaning:

• username: that specific user
• ALL: from any host (on multi-host systems)
• (ALL:ALL): run commands as any user and any group
• ALL: may run any command

Example: Passwordless sudo for one user

This is more risky, but sometimes used on test systems or automation:

username ALL=(ALL:ALL) NOPASSWD: ALL 

Now username can run sudo commands without being asked for their password.

4. Granting Limited sudo Access (Specific Commands Only)

You don’t have to give a user full root power. You can allow only certain commands via sudo.

Example: allow backupuser to restart a specific service and read logs, but nothing else:

backupuser ALL=(root) NOPASSWD: /bin/systemctl restart myapp.service, /usr/bin/journalctl -u myapp.service 

Key points:

• List full paths to commands (which command can help find them)
• Separate multiple commands with commas
• You can decide whether to require a password or not (NOPASSWD: vs requiring one)

This approach is useful when:

• You run a server and want to keep some control while delegating a few tasks.
• You have developers who need to manage a specific service but not the whole system.
• You’re building scripts or automation that rely on sudo for just a couple of commands.

Typical Differences Between Distros and Setups

The basic ideas are the same everywhere, but the default groups and config style vary.

On some older or more locked-down systems:

• sudo may not be installed by default
• The main admin may use su to switch to root instead
• You might have stricter defaults like no passwordless sudo anywhere

Key Variables That Change How You Should Add a User to sudoers

How you proceed safely depends on several factors. The most important ones:

1. Linux Distribution and Version

• Determines whether you use sudo, wheel, or another group
• Affects default sudoers file contents
• Impacts where extra config is expected (/etc/sudoers.d/ vs only /etc/sudoers)

2. Type of System (Desktop vs Server, Personal vs Shared)

• Personal laptop or PC: You might be comfortable giving your main account full sudo via the standard admin group.
• Production server: You may want to restrict users to:
  • Specific commands
  • Logged sudo usage
  • No passwordless full root access

3. Security Requirements and Policies

If you’re in a company or managed environment, you might have rules like:

• No NOPASSWD entries allowed
• No direct edits to /etc/sudoers — only files under /etc/sudoers.d/
• Commands must be as narrowly defined as possible

On a home machine, you might accept a simpler, more permissive setup.

4. User’s Role and Skill Level

• Beginner users given full sudo access are more likely to run something harmful by accident.
• Experienced admins or developers may need more control, but also know the risks.
• Automation users (CI services, backup scripts) often need very specific, non-interactive sudo rules.

5. How You Access the System

• Local access: If you break sudo, you might still fix things via a root login or recovery mode.
• Remote-only server: A broken sudo file can leave you stuck unless you have:
  • Console / out-of-band management
  • A second account with working sudo
  • Another root-level access method

Different User Profiles, Different sudo Strategies

Because of those variables, “how to add a user to sudoers” looks different for different people.

Home Desktop or Laptop User

Common pattern:

• Install Ubuntu/Debian-style distro
• Main user is automatically in the sudo group
• You might only occasionally add another user (family member, secondary account)

In this case, adding a user to the sudo group is often enough:

sudo usermod -aG sudo newuser 

And you probably don’t need fine-grained sudoers edits.

Small Server Admin or Self-Hosted Services

Here you might:

• Keep a primary admin account with full sudo via a group
• Add service accounts with extremely limited sudo permissions for:
  • Restarts
  • Deploy commands
  • Log access

You’ll lean more on:

• /etc/sudoers.d/ for per-user or per-service rules
• Command-specific lines rather than “ALL=(ALL) ALL”

Corporate or Team Environment

You may have:

• Centralized user management
• Policies about who can be in sudo or wheel
• Scripts or tools that manage /etc/sudoers.d/ automatically

Here, editing /etc/sudoers by hand may be discouraged or disallowed. You might work with:

• Predefined sudo roles
• Group-based rules tied to corporate identity systems

Where Your Own Setup Fits In

The core mechanics of adding a user to sudoers are:

• Decide between group-based sudo vs per-user sudoers rules
• Use usermod -aG to update groups, or
• Use visudo to safely adjust /etc/sudoers or files in /etc/sudoers.d/
• Choose between full vs limited sudo, and password vs passwordless

The “right” way for you depends on:

• Which Linux distribution you’re running
• Whether it’s a personal machine, a home server, or a production system
• How comfortable the user is with command-line tools
• How strict your security expectations are

Once you map your own system and needs against these choices, the exact commands and sudoers rules become much clearer.