Direct root login is a significant security risk that should be avoided regardless of the environment. Instead, administrative tasks should be performed through sudo with carefully configured permissions that grant only the necessary privileges to specific users or groups. This approach provides better security, accountability, and audit trails.

This guide demonstrates how to configure sudo with user aliases and command aliases to create granular permission systems on both AlmaLinux/RHEL and Ubuntu systems.

Prerequisites

• Root access to configure initial sudo settings
• Understanding of your administrative requirements
• Knowledge of which commands specific users need access to
• Familiarity with the visudo command

Why Avoid Direct Root Access

Security Benefits of Sudo:

• Individual user accountability through logging
• Granular permission control per user/command
• Temporary privilege escalation instead of persistent root access
• Easier credential management and rotation
• Audit trail of administrative actions

Basic Sudo Configuration Structure

The sudoers file uses three main components for advanced configurations:

User Aliases: Group users with similar access needs Command Aliases: Group related commands for easier management
Host Aliases: Define different machines (for shared sudoers files)

AlmaLinux/RHEL Configuration

Edit the Sudoers File

Always use visudo to edit the sudoers file safely:

sudo visudo

Configure User and Command Aliases

Add these configurations to create restricted administrative access:

## User Aliases - Group users by function
User_Alias ADMINS = john
User_Alias DEVELOPERS = alice, bob
User_Alias OPERATORS = mike, sarah

## Command Aliases - Group related commands
Cmnd_Alias SERVICES = /usr/bin/systemctl *
Cmnd_Alias PACKAGES = /usr/bin/yum, /usr/bin/dnf, /bin/rpm
Cmnd_Alias NETWORKING = /sbin/ip, /usr/bin/netstat, /sbin/ss
Cmnd_Alias LOGS = /usr/bin/tail, /usr/bin/less, /usr/bin/grep

## Grant specific permissions
ADMINS ALL=(ALL) SERVICES, PACKAGES
DEVELOPERS ALL=(ALL) NOPASSWD: SERVICES
OPERATORS ALL=(ALL) NOPASSWD: LOGS, NETWORKING

Configuration Breakdown

ADMINS Group:

• Can manage services and packages
• Requires password for security
• Full systemctl access for service management

DEVELOPERS Group:

• Can restart/manage services without password
• Useful for application deployment and testing
• Limited to service management only

OPERATORS Group:

• Read-only access to logs and network status
• No password required for monitoring tasks
• Cannot modify system configuration

Ubuntu Configuration

Ubuntu-Specific Setup

Ubuntu uses slightly different default configurations:

sudo visudo

Add the following configuration:

## User alias specification
User_Alias TRAINING = john
User_Alias WEBADMINS = alice, bob
User_Alias MONITORS = sarah, mike

## Command alias specification
Cmnd_Alias PKGMGR = /usr/bin/apt, /usr/bin/apt-get, /usr/bin/dpkg
Cmnd_Alias SVC = /bin/systemctl, /usr/bin/systemctl
Cmnd_Alias WEBTOOLS = /usr/bin/nginx, /usr/bin/apache2ctl
Cmnd_Alias READONLY = /usr/bin/tail, /usr/bin/less, /bin/cat

## User privilege specification
TRAINING ALL=(ALL) NOPASSWD: PKGMGR, SVC
WEBADMINS ALL=(ALL) SVC, WEBTOOLS
MONITORS ALL=(ALL) NOPASSWD: READONLY

Ubuntu Configuration Details

TRAINING Group:

• Package management access without password
• Service control for development/learning
• Good for training environments

WEBADMINS Group:

• Web server management capabilities
• Service control with password requirement
• Focused on web infrastructure

MONITORS Group:

• Read-only access to system files
• Monitoring and troubleshooting permissions
• No system modification capabilities

Security Best Practices

Password vs. NOPASSWD

Use NOPASSWD for:

• Read-only operations (log viewing, status checks)
• Frequent development tasks
• Automated scripts (with careful consideration)

Require passwords for:

• System-modifying operations
• Package installation/removal
• Service configuration changes
• Production system access

Example Secure Configurations

Development Server:

User_Alias DEVS = developer1, developer2
Cmnd_Alias DEVTOOLS = /usr/bin/systemctl restart myapp, /usr/bin/systemctl status *
DEVS ALL=(ALL) NOPASSWD: DEVTOOLS

Production Server:

User_Alias PRODUCTION_ADMINS = admin1, admin2
Cmnd_Alias PROD_SERVICES = /usr/bin/systemctl start, /usr/bin/systemctl stop, /usr/bin/systemctl restart
PRODUCTION_ADMINS ALL=(ALL) PROD_SERVICES

Common Command Alias Examples

System Administration

Cmnd_Alias SYSTEM = /usr/bin/systemctl *, /bin/mount, /bin/umount
Cmnd_Alias NETWORK = /sbin/ip *, /usr/bin/netstat, /sbin/ss
Cmnd_Alias FIREWALL = /usr/bin/firewall-cmd *, /sbin/iptables

Application Management

Cmnd_Alias DOCKER = /usr/bin/docker *, /usr/bin/docker-compose *
Cmnd_Alias DATABASE = /usr/bin/mysql, /usr/bin/psql
Cmnd_Alias BACKUP = /usr/bin/rsync *, /bin/tar *

Monitoring and Logs

Cmnd_Alias MONITORING = /usr/bin/htop, /usr/bin/iotop, /usr/bin/nethogs
Cmnd_Alias LOGVIEW = /usr/bin/tail *, /usr/bin/less *, /usr/bin/journalctl *

Verification and Testing

Test Sudo Configuration

Verify your configuration without logging out:

# Test specific command access
sudo -l

# Test as specific user (from root)
sudo -u john sudo -l

# Validate sudoers syntax
visudo -c

Check User Permissions

Users can verify their available commands:

# List available sudo commands
sudo -l

# Test specific command
sudo systemctl status nginx

Troubleshooting Common Issues

Syntax Errors

# Always check syntax before saving
visudo -c

# If locked out, boot to single-user mode or use recovery

Permission Denied

# Check user is in correct alias
sudo -l

# Verify command path matches alias
which systemctl

Wildcard Issues

# Be specific with wildcards
Cmnd_Alias SERVICES = /usr/bin/systemctl *

# Avoid overly broad permissions
# BAD: Cmnd_Alias DANGEROUS = /usr/bin/* 

Conclusion

Proper sudo configuration eliminates the need for direct root access while providing granular control over administrative privileges. By using user aliases and command aliases, you can create maintainable permission structures that scale with your organization’s needs.

Remember: The goal is to provide users with exactly the privileges they need to perform their jobs—no more, no less.

Linux Administration: Proper Sudo Configuration for Limited Privilege Access