How To Add Users To The Sudoer File On Linux

Adding a user to the sudoer file on Linux sounds like the kind of task that should require a wizard robe, a dark terminal window, and perhaps a dramatic thunderclap. In reality, it is a practical system administration job: you are deciding who can run administrative commands with sudo. That power is useful, but it also deserves respect. Give it to the wrong account, write one careless rule, or edit the sudoers file incorrectly, and your server may politely turn into a locked filing cabinet with blinking lights.

This guide explains how to add users to sudoers on Linux safely, including the recommended group-based method, the direct sudoers file method, and the cleaner /etc/sudoers.d/ approach. You will also learn how to test sudo access, avoid common mistakes, and apply real-world best practices that keep your Linux system secure instead of “exciting” in the bad way.

What Is the Sudoers File?

The sudoers file is the configuration file that tells Linux which users or groups are allowed to run commands as another user, usually root. On most systems, the main file lives here:

When a user types a command such as:

Linux checks the sudo policy. If the user is authorized, the command runs with elevated privileges. If not, the system responds with a familiar message that roughly translates to: “Nice try, but no.”

The sudoers configuration can define broad access, limited access, password requirements, command restrictions, and group-based permissions. That makes it powerful, but it also means syntax matters. A tiny typo in /etc/sudoers can break sudo access, which is why the first rule of sudoers club is simple: do not edit the file carelessly.

Before You Start: Important Safety Rules

Always Use visudo

Never open /etc/sudoers with a regular text editor unless you enjoy living dangerously. Use visudo instead. The visudo command locks the sudoers file while editing and checks the syntax before saving changes. This helps prevent mistakes that could disable administrative access.

If you need to edit a file inside /etc/sudoers.d/, use:

Keep One Root or Sudo Session Open

When changing sudo permissions on a remote server, keep your current privileged session open until you confirm the new account works. Do not log out immediately after editing. Test first, celebrate second.

Prefer Groups Over Individual User Rules

For most Linux systems, the easiest and safest way to give sudo access is to add the user to the correct administrative group. On Ubuntu and Debian-based distributions, that group is usually sudo. On Red Hat, CentOS, Rocky Linux, AlmaLinux, and Fedora systems, it is commonly wheel.

Method 1: Add a User to the Sudo Group on Ubuntu or Debian

On Ubuntu, Debian, Linux Mint, and many related distributions, members of the sudo group are allowed to run administrative commands. This is the recommended method for regular administrator accounts.

Step 1: Check Whether the User Exists

First, confirm the user account exists:

Replace username with the actual Linux username. For example:

If the user does not exist, create one:

On some distributions, you may use:

Step 2: Add the User to the sudo Group

Run the following command:

The -aG options are important. The -G option sets supplementary groups, and -a appends the new group without removing existing group memberships. Forgetting -a is like adding someone to the guest list by erasing the entire guest list first. Not ideal.

Step 3: Confirm Group Membership

Check the user’s groups:

You should see sudo in the output.

Step 4: Log Out and Back In

Group membership changes usually apply after the user logs out and logs back in. If you are testing locally, switch to the user:

Then test sudo:

If everything works, the output should be:

Method 2: Add a User to the Wheel Group on RHEL, CentOS, Fedora, Rocky Linux, or AlmaLinux

On Red Hat-based systems, sudo access is typically managed through the wheel group. This includes Red Hat Enterprise Linux, CentOS Stream, Fedora, Rocky Linux, and AlmaLinux.

Step 1: Create the User If Needed

Step 2: Add the User to the wheel Group

Step 3: Verify the User’s Groups

You should see wheel listed.

Step 4: Test sudo Access

If the command returns root, the user has sudo privileges.

Method 3: Add a User Directly to the Sudoers File

Sometimes you may want to grant sudo privileges to a specific user without adding them to a general admin group. This is useful for custom access rules, limited command permissions, or special service accounts. However, direct sudoers entries should be used carefully because they can become messy over time.

Open the Sudoers File Safely

Add a line like this:

Here is what that means:

• alex is the username.
• ALL means the rule applies from any host.
• (ALL:ALL) means the user can run commands as any user and any group.
• The final ALL means the user can run all commands.

Save and exit. If there is a syntax error, visudo will warn you before installing the file. Listen to it. It is the tiny seatbelt of Linux administration.

Method 4: Use /etc/sudoers.d/ for Cleaner Sudo Rules

A cleaner approach is to create a separate sudoers rule file under /etc/sudoers.d/. This avoids cluttering the main /etc/sudoers file and makes future audits easier.

Create a Dedicated Rule File

Add the rule:

Save and exit. Then check permissions:

Avoid using file names with dots, backup suffixes, or editor leftovers. Simple names such as alex, 90-admins, or deploy-user are safer choices.

How To Grant Passwordless Sudo Access

Passwordless sudo can be convenient for automation, deployment scripts, and controlled service accounts. It can also be risky if used too broadly. If you give a normal human user passwordless access to every command, you are basically handing them the root keys and saying, “Please do not press the shiny red button.”

Passwordless Access for All Commands

To allow a user to run all sudo commands without a password, use:

This works, but it is usually not the best security choice.

Better: Passwordless Access for One Command

A safer rule allows passwordless access only to a specific command:

This lets alex restart Nginx without entering a password, but it does not give unlimited root power. That is the difference between giving someone a house key and giving them a bulldozer.

How To Give a Group Sudo Access

Managing sudo access by group is efficient when multiple users need similar permissions. For example, you can create a group for deployment users:

Then create a sudoers rule:

Add:

The percent sign means the rule applies to a group, not an individual user. This setup is easier to manage because you can add or remove users from the group without editing sudoers every time.

How To Check a User’s Sudo Privileges

After adding a user to sudoers, always test the configuration. You can list the commands a user is allowed to run with:

From the user account, run:

To force sudo to ask for authentication again before testing, use:

Then test:

If the result is root, sudo is working.

How To Validate the Sudoers Configuration

You can check sudoers syntax without making changes:

A healthy configuration should return messages showing that the sudoers files parsed correctly. This is especially useful after creating files in /etc/sudoers.d/.

How To Remove Sudo Access

Removing sudo access is just as important as granting it. Old admin accounts are like old keys under the doormat: convenient until someone remembers they exist.

Remove a User from the sudo Group

On Ubuntu or Debian:

Remove a User from the wheel Group

On RHEL-based systems:

Remove a Custom Sudoers Rule

If you created a dedicated file in /etc/sudoers.d/, remove it:

Always validate the configuration after removing sudo rules.

Common Sudoers Mistakes To Avoid

Editing /etc/sudoers Without visudo

This is the classic mistake. A syntax error can lock you out of sudo. Use visudo, even if you are confident. Especially if you are confident.

Forgetting the -a Option in usermod

Running usermod -G sudo alex without -a may replace the user’s supplementary groups. The safer command is:

Giving Everyone NOPASSWD Access

Passwordless sudo is useful in specific cases, but broad passwordless access weakens security. Use it sparingly and scope it to exact commands when possible.

Using Relative Command Paths

When writing command-specific sudoers rules, use full paths such as /usr/bin/systemctl. Find the path with:

Not Testing Before Logging Out

Always test sudo access in a second session before closing your current administrative shell. This habit can save you from emergency recovery mode, cloud console panic, and the unique sadness of realizing you locked yourself out.

Best Practices for Secure Sudo Access

Good sudo management is not just about making commands work. It is about keeping administrative access controlled, auditable, and easy to revoke.

• Use groups for standard admin access.
• Use /etc/sudoers.d/ for custom rules.
• Use visudo every time.
• Grant the least privilege needed.
• Avoid broad NOPASSWD rules for human users.
• Review sudo access regularly.
• Remove privileges immediately when users change roles.
• Keep root access limited and monitored.

Troubleshooting: User Is Not in the Sudoers File

If a user sees this error:

It means the user does not have sudo privileges. To fix it, log in as root or another sudo-enabled account and add the user to the correct group:

Or, on Red Hat-based systems:

Then have the user log out and back in. If the issue continues, check the sudoers file with:

Also confirm the group rule exists in sudoers. For Debian and Ubuntu, you may see something like:

For Red Hat-based systems, you may see:

Practical Examples

Example 1: Give Full Sudo Access to a New Ubuntu Admin

If the output is root, Maria is ready to administrate the system.

Example 2: Give Full Sudo Access on Rocky Linux

Example 3: Allow a Deployment User to Restart Only Nginx

Add:

This is useful for CI/CD workflows where a deployment account needs one controlled administrative action.

Real-World Experience: Lessons From Adding Users to Sudoers

In real Linux administration, adding users to sudoers is rarely just a command you copy and paste. It is a small decision with a large security shadow. The first practical lesson is that group-based sudo access is usually the cleanest path. When an organization has five administrators, adding each one to the sudo or wheel group is simple. When that organization grows to fifty users, direct entries in /etc/sudoers can become a cluttered museum of forgotten permissions. Nobody wants to find a rule for an intern from three summers ago who can still restart production services.

Another lesson is to test sudo access like you are expecting failure. Open a second terminal, switch to the user, run sudo -l, and test a harmless command such as sudo whoami. This takes seconds, but it prevents long troubleshooting sessions. On remote servers, this habit is priceless. Closing your only working root session before confirming the new sudo rule is like locking your keys in the car while the engine is running and the car is a cloud server.

Using /etc/sudoers.d/ is also a habit worth building. Separate rule files make permissions easier to audit. For example, a file named deploy-nginx clearly explains its purpose before anyone even opens it. Compare that with a giant sudoers file full of one-off rules, mysterious comments, and ancient usernames. Future you will appreciate clean organization, and future you is probably already tired.

One important security experience is that NOPASSWD should not be treated as a convenience setting for everyone. It is best reserved for automation or carefully limited commands. If a script needs to restart one service, give it permission to restart that service only. Do not grant full passwordless root access just because it makes the first test pass. The first test passing is nice; the security audit passing is better.

It is also smart to document why sudo access was granted. A short comment in a sudoers.d file can save confusion later:

Finally, sudo access should have an expiration mindset. People change roles, contractors finish projects, and temporary accounts have a funny way of becoming permanent if nobody checks. Schedule regular reviews of users in the sudo and wheel groups. Run commands such as getent group sudo or getent group wheel and confirm that every account still belongs there. Good Linux security is not about being paranoid; it is about being tidy. And in system administration, tidy usually wins.

Conclusion

Adding users to the sudoer file on Linux is straightforward when you follow the right method. For most systems, the best approach is to add users to the appropriate admin group: sudo on Ubuntu and Debian-based distributions, or wheel on Red Hat-based distributions. For custom permissions, use visudo and place clean, focused rules in /etc/sudoers.d/.

The key is balance. Sudo access should be convenient enough for real work but restricted enough to protect the system. Use groups, validate syntax, test before logging out, avoid unnecessary passwordless access, and review privileges regularly. Do that, and sudo becomes what it should be: a safe bridge to administrative power, not a trapdoor into server chaos.

Note: This article is based on standard Linux sudo behavior and current common practices across major distributions, including Debian-based and Red Hat-based systems.