sudo Configuration

Applies to CentOS Stream 9 & 10 / AlmaLinux 9.x & 10.x / Rocky Linux 9.x & 10.x

sudo allows regular users to execute commands as another user (typically root) without knowing the root password. Properly configuring sudo is a critical aspect of server security management.

What You Will Learn

• How sudo works and basic usage
• Safely editing the sudoers file with visudo
• sudoers file syntax
• Configuring sudo privileges for users and groups
• NOPASSWD configuration
• sudo log auditing
• The wheel group on EL systems

Prerequisites

• A system with EL 9.x installed
• Currently have sudo privileges or can log in as root
• Familiarity with the basics of User and Group Management

sudo Basics

How sudo Works

When you execute sudo <command>:

1. The system checks the /etc/sudoers file to verify whether the current user has permission
2. The user is prompted to enter their own password (not the root password)
3. After successful verification, the command is executed as the target user (root by default)
4. The action is recorded in the system log

Execute a command as root

$ sudo systemctl restart nginx
[sudo] password for admin:

Execute a command as another user

$ sudo -u postgres psql

View the current user's sudo privileges

$ sudo -l

Example output:

Matching Defaults entries for admin on myserver:
    !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
    env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
    secure_path=/sbin:/bin:/usr/sbin:/usr/bin

User admin may run the following commands on myserver:
    (ALL) ALL

Tip

After the first use of sudo, the password is cached for a period (5 minutes by default), so you do not need to re-enter it for subsequent sudo commands during that time.

The wheel Group on EL Systems

On EL systems, the wheel group is the default administrator group. Users belonging to the wheel group have full sudo privileges.

View wheel group members

$ getent group wheel
wheel:x:10:admin

Add a user to the wheel group to grant sudo privileges

$ sudo usermod -aG wheel newadmin

Note

After adding a user to the wheel group, the user needs to log out and back in for the new group membership to take effect.

This is the default wheel group configuration in /etc/sudoers:

View the wheel configuration in sudoers

$ sudo grep wheel /etc/sudoers
## Allows people in group wheel to run all commands
%wheel  ALL=(ALL)       ALL

Editing sudoers with visudo

Caution

Never edit the /etc/sudoers file directly with a text editor. A syntax error could prevent all users from using sudo, locking you out of the system.

The visudo command automatically checks for syntax errors when saving:

Edit sudoers using visudo

$ sudo visudo

If you want to use a different editor:

Use vim as the visudo editor

$ sudo EDITOR=vim visudo

Using the /etc/sudoers.d/ Directory

It is recommended to place custom configurations in the /etc/sudoers.d/ directory rather than modifying the main /etc/sudoers file directly:

Create a custom sudoers configuration

$ sudo visudo -f /etc/sudoers.d/custom-rules

Tip

The benefit of using the /etc/sudoers.d/ directory: system upgrades will not overwrite your custom configurations, and it is easier to manage and track changes.

Confirm that the main file includes a reference to this directory (EL 9 includes it by default):

Confirm sudoers references the sudoers.d directory

$ sudo grep "includedir" /etc/sudoers
#includedir /etc/sudoers.d

Note

The # before #includedir is not a comment — it is part of the sudoers file directive syntax. This line is actually active.

sudoers Syntax Explained

Basic Format

user  host=(target-user:target-group)  command

Part descriptions:

Part	Description
User	The authorized username; prefix group names with %
Host	The host this rule applies to; ALL means all hosts
Target user	The user that can be switched to; ALL means all users
Target group	The group that can be switched to (optional)
Command	The commands allowed; ALL means all commands

Common Configuration Examples

Allow user deploy to execute all commands

deploy  ALL=(ALL)  ALL

Allow all members of the developers group to execute all commands

%developers  ALL=(ALL)  ALL

Allow a user to execute only specific commands

webadmin  ALL=(ALL)  /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx

Allow a user to execute commands as the postgres user

dbadmin  ALL=(postgres)  ALL

Deny a user from executing certain commands

operator  ALL=(ALL)  ALL, !/usr/bin/su, !/usr/bin/passwd root

Command Aliases

When multiple users need the same privileges, aliases can simplify the configuration:

Define command aliases

Cmnd_Alias WEB_CMDS = /usr/bin/systemctl restart nginx, \
                       /usr/bin/systemctl reload nginx, \
                       /usr/bin/systemctl status nginx

Cmnd_Alias PKG_CMDS = /usr/bin/dnf install *, \
                       /usr/bin/dnf update *, \
                       /usr/bin/dnf remove *

Use command aliases

webadmin  ALL=(ALL)  WEB_CMDS
pkgadmin  ALL=(ALL)  PKG_CMDS

You can also define user aliases and host aliases:

Define a user alias

User_Alias WEBTEAM = zhangsan, lisi, wangwu
WEBTEAM  ALL=(ALL)  WEB_CMDS

NOPASSWD Configuration

By default, using sudo requires the user to enter their own password. You can configure password-free execution:

Allow a user to execute all commands without a password

deploy  ALL=(ALL)  NOPASSWD: ALL

Password-free for specific commands only

monitor  ALL=(ALL)  NOPASSWD: /usr/bin/systemctl status *, /usr/bin/journalctl

wheel group password-free (not recommended for production)

%wheel  ALL=(ALL)  NOPASSWD: ALL

Caution

NOPASSWD: ALL should be used with caution. It is appropriate for automated deployment accounts or CI/CD pipelines, but is not recommended for everyday administrator accounts. For human users, configure password-free access only for specific commands whenever possible.

Mixing PASSWD and NOPASSWD

Some commands password-free, others require a password

operator  ALL=(ALL)  NOPASSWD: /usr/bin/systemctl status *, PASSWD: /usr/bin/systemctl restart *

sudo Log Auditing

All sudo operations are recorded in the system log, which is essential for security auditing.

View sudo logs (using journalctl)

$ sudo journalctl -u sudo

View sudo records in /var/log/secure

$ sudo grep sudo /var/log/secure

Example output:

Mar 24 14:30:22 myserver sudo: admin : TTY=pts/0 ; PWD=/home/admin ; USER=root ; COMMAND=/usr/bin/systemctl restart nginx

Configure Detailed Logging

You can configure additional logging options in sudoers:

Edit sudoers to add logging configuration

$ sudo visudo -f /etc/sudoers.d/logging

Enable sudo command logging

Defaults  log_input, log_output
Defaults  logfile="/var/log/sudo.log"
Defaults  iolog_dir="/var/log/sudo-io/%{seq}"

Note

log_input and log_output record all input and output from sudo sessions. This is useful in security compliance environments but consumes additional disk space.

Practical Example: Configuring Multi-Level Privileges

The following example demonstrates how to configure different sudo privileges for different roles.

1. Create the role configuration file

   Create a custom sudoers file

   $ sudo visudo -f /etc/sudoers.d/team-roles

2. Define command aliases

   # Service management commands
   Cmnd_Alias SVC_CMDS = /usr/bin/systemctl start *, \
                          /usr/bin/systemctl stop *, \
                          /usr/bin/systemctl restart *, \
                          /usr/bin/systemctl reload *, \
                          /usr/bin/systemctl status *
   
   # Read-only monitoring commands
   Cmnd_Alias MON_CMDS = /usr/bin/systemctl status *, \
                          /usr/bin/journalctl *, \
                          /usr/bin/top, \
                          /usr/bin/htop, \
                          /usr/bin/ss, \
                          /usr/bin/df, \
                          /usr/bin/free

3. Assign privileges

   # Operations staff: full service management privileges
   %ops  ALL=(ALL)  SVC_CMDS
   
   # Monitoring staff: read-only privileges, no password required
   %monitors  ALL=(ALL)  NOPASSWD: MON_CMDS
   
   # Deployment account: full privileges, no password
   deploy  ALL=(ALL)  NOPASSWD: ALL

4. Create the corresponding groups and add users

   Create groups and add users

   $ sudo groupadd ops
   $ sudo groupadd monitors
   $ sudo usermod -aG ops zhangsan
   $ sudo usermod -aG monitors lisi

5. Verify the configuration

   Verify zhangsan's privileges

   $ sudo -U zhangsan sudo -l

Common sudo Options

Command	Description
sudo <command>	Execute a command as root
sudo -u <user> <command>	Execute a command as a specified user
sudo -l	List the current user’s sudo privileges
sudo -U <user> -l	List a specified user’s sudo privileges (requires root)
sudo -i	Switch to root’s login shell
sudo -s	Start a shell as root (without switching environment)
sudo -k	Clear the sudo password cache
sudo -v	Refresh the password cache timeout

Common Issues

”xxx is not in the sudoers file”

The user does not have sudo privileges. Add the user to the wheel group as root:

Operate as root

$ su -
# usermod -aG wheel username
# exit

Tip

If you do not know the root password and there are no users with sudo privileges, you will need to enter single-user mode (rescue mode) to reset. See Boot Troubleshooting.

”syntax error” Prevents sudo from Working

If you incorrectly edited /etc/sudoers directly and introduced a syntax error:

Method 1: If you have another user with sudo privileges or can log in as root:

Fix the sudoers syntax

$ su -
# visudo

Method 2: If you cannot log in as root, you will need to enter rescue mode.

Caution

This is exactly why you should always use visudo instead of editing /etc/sudoers directly. visudo checks the syntax before saving and prevents you from saving an invalid configuration.

How to Adjust the sudo Password Cache Duration

Set the password cache timeout to 15 minutes

$ sudo visudo -f /etc/sudoers.d/timeout

Defaults  timestamp_timeout=15

Set to 0 to require a password every time. Set to -1 to never expire (not recommended).

How to Use sudo in Scripts

For automated scripts, it is recommended to configure NOPASSWD privileges for the script-executing user (limited to specific commands) to avoid the script hanging at a password prompt.

Configure password-free access for automation scripts

deploy  ALL=(ALL)  NOPASSWD: /usr/bin/systemctl restart myapp, /usr/bin/dnf update myapp

Further Reading

• User and Group Management — Creating and managing users and groups
• File Permissions and ACLs — File-level permission control
• SSH Security Configuration — Remote access security
• man sudo / man sudoers — Complete reference manuals