How to Create a Sudo User on CentOS and Rocky Linux: wheel Group and sudoers Configuration Guide

This guide explains how to create a regular user with sudo privileges on CentOS and Rocky Linux. It covers two standard approaches—granting access through the wheel group and assigning permissions directly in /etc/sudoers—to solve common privilege escalation and least-privilege administration tasks. Keywords: CentOS, Rocky Linux, sudo.

Technical Specifications at a Glance

Parameter	Description
Supported Systems	CentOS, Rocky Linux
Core Capabilities	Create users, grant sudo privileges, verify privilege escalation
Key Mechanisms	wheel group, /etc/sudoers
Main Commands	ssh, adduser, passwd, usermod, visudo, su, sudo
Required Privileges	root or equivalent administrator access
License	Original page marked as CC 4.0 BY-SA
Star Count	Not provided in the source content
Core Dependencies	sudo, shadow-utils, Vim/visudo

There Are Two Standard Ways to Grant sudo Privileges on CentOS and Rocky Linux

On Red Hat-based distributions, the safest and most common method is to add the user to the wheel group. This approach is simple, auditable, and aligned with standard enterprise Linux administration practices.

The second method is to edit /etc/sudoers directly. It offers more flexibility, but a bad edit can break sudo entirely. For that reason, you should always use visudo instead of editing the file with a standard text editor.

You Should Confirm That You Have Administrative Access First

If you are working locally, you can log in as root directly. If you are connecting to a remote server, start by opening an SSH session.

ssh root@server_ip_address  # Connect to the target server as root

This command gives you access to the target host. Every authorization step that follows requires administrator privileges.

Granting Access Through the wheel Group Is the Recommended Approach

CentOS and Rocky Linux use the wheel group for sudo privileges by default. After you add a regular user to this group, that user can elevate privileges only when needed instead of working as root full time.

Create the new user first, then set a login password. This separates day-to-day work from privileged operations and reduces the risk of accidental configuration removal or unsafe command execution.

adduser user1        # Create a regular user
passwd user1         # Set a password for the new user

These two commands initialize the account. In most cases, adduser does not print a success message.

AI Visual Insight: The image shows the interactive password setup flow after running passwd user1 in the terminal. It highlights the two critical steps—entering the new password and confirming it—and demonstrates that Linux does not echo password input, which helps prevent shoulder surfing and log exposure.

You Should Use visudo to Verify That the wheel Rule Is Enabled

On some system images, the wheel rule may be commented out. In that case, even if the user belongs to the group, sudo still will not work.

visudo  # Open the sudoers configuration file safely

This command protects you with syntax validation so that a broken configuration does not disable sudo after you save the file.

AI Visual Insight: The image shows that the rule related to %wheel ALL=(ALL) ALL in /etc/sudoers is commented out with #. That means members of the wheel group do not currently receive sudo privileges automatically. This is one of the most important checks during troubleshooting.

AI Visual Insight: The image shows the sudoers configuration after the rule has been uncommented. The key change is the removal of the leading #, which activates %wheel ALL=(ALL) ALL and enables group-based sudo authorization.

Adding the Target User to the wheel Group Completes the Authorization

After you confirm that the rule is active, use usermod -aG to append the user to the group. Here, -a means append and -G specifies the supplementary group list. If you omit -a, you may overwrite the user’s existing supplementary groups.

usermod -aG wheel user1  # Append user1 to the wheel group

This is the key authorization step. If it succeeds, it usually produces no output.

You Should Switch Users and Verify That sudo Works

After you grant access, do not stop there. Best practice is to switch to the target user immediately and verify that both the command path and password policy work as expected.

su - user1              # Switch to the target user's environment
sudo whoami             # Verify that sudo returns root

If the output is root, the user has successfully received sudo privileges.

AI Visual Insight: The image shows that the shell prompt changes after su - user1, which indicates that the session has switched to the new user’s full login environment rather than only changing the effective UID.

AI Visual Insight: The image demonstrates the standard sudo whoami verification flow: enter the regular user’s password first, then receive root as output. This is the smallest complete validation loop for confirming successful sudo authorization.

Editing the sudoers File Directly Fits Fine-Grained Access Control Scenarios

If your organization does not want to rely on groups, or if you need to grant privileges to only one specific account, editing /etc/sudoers directly is a better fit. This method lets you control the user, host, target identity, and command scope with precision.

You should still use visudo to open the file because it validates syntax before saving and helps prevent formatting mistakes that could disable sudo.

visudo  # Safely edit /etc/sudoers

The real value of this step is not just opening the file. It is saving the file with built-in validation.

Adding an Explicit Rule for a Specific User Grants Access

Add the following rule to sudoers to grant full sudo privileges to the user. In production, if you need stronger security, you can narrow this down to a whitelist of specific commands.

user1 ALL=(ALL) ALL  # Allow user1 to run sudo commands as any target user

This rule means that user1 can run all permitted commands on all hosts as any target user.

AI Visual Insight: The image shows where the user authorization section appears within the sudoers file. It indicates that you should place the new rule near existing authorization blocks to keep the configuration structure clear and reduce maintenance ambiguity.

AI Visual Insight: The image clearly shows that user1 ALL=(ALL) ALL has been added in the Vim editing interface. This means the user-level sudo authorization rule has been written to disk and takes effect immediately as long as the syntax is valid.

Verifying the Result Again Is Required Before Production Use

Switch to the account and run sudo whoami again. If the result is still root, the direct sudoers configuration is working.

su - user1              # Switch to the authorized user
sudo whoami             # Verify sudo output again

This step confirms that the user-specific rule is not being overridden by a higher-priority policy.

AI Visual Insight: The image shows the final terminal output returning root, which proves that the explicit sudoers authorization path has been recognized and executed successfully by the system.

You Should Follow the Principle of Least Privilege in Production

If you are handling routine operations, prefer the wheel group because it simplifies auditing and bulk user management. If you are dealing with special-purpose accounts, automation accounts, or restricted operators, then user-specific sudoers rules may be more appropriate.

You should also avoid using root directly for long-term daily work. A better model is to log in as a regular user and elevate with sudo only for sensitive tasks. This makes responsibility boundaries easier to trace and aligns better with security and compliance requirements.

FAQ

1. Why is adding a user to the wheel group recommended instead of editing sudoers directly?

Because the wheel group is easier to maintain, better for bulk authorization, and less likely to introduce accidental changes to /etc/sudoers. For standard operations work, it is usually the default best practice.

2. Why must I use visudo instead of editing /etc/sudoers directly?

visudo checks for syntax errors before saving. If the sudoers format becomes invalid, the system may no longer allow sudo at all, which can also complicate remote operations recovery.

3. What should I do if sudo whoami does not return root?

Check these three things first: whether the user has been added to the wheel group, whether %wheel ALL=(ALL) ALL has been uncommented, and whether the current session has been re-logged in or switched correctly with su - user1.

AI Readability Summary

This article provides a structured walkthrough of the two standard ways to create a sudo-enabled user on CentOS and Rocky Linux: adding the user to the wheel group or editing the sudoers file directly. It covers prerequisites, command steps, privilege verification, common risks, and best practices, making it suitable for Linux administration and operations scenarios.