/// article
Linux sudoers Configuration Guide: Permissions, Logging, and Security
A system administrator who assumes the role of the root user can permit other normal system users with the help of sudo command and a few configurations to run some commands as well as carry out a number of vital system operations including the ones mentioned above. Alternatively, the system administrator can share the root user password (which is not a r...
Managing administrative privileges is an important part of Linux server security. Whether you manage a personal Ubuntu server, a production web server, or hundreds of Linux systems, you need to control who can perform privileged operations. Linux provides the sudo command to execute commands with another user’s privileges, typically those of the root account. The sudoers configuration determines which users can execute those commands and under what conditions. A poorly configured sudo policy can expose an entire system to unnecessary security risks. Granting unrestricted root privileges, allowing unsafe environment variables, or failing to monitor administrative activity can make security incidents more difficult to prevent and investigate. In this guide, we will configure sudo permissions, manage authentication behavior, enable logging, and create restricted access for common server administration tasks. The examples focus on Ubuntu and Debian, although most concepts also apply to RHEL, Rocky Linux, AlmaLinux, and other distributions using sudo. Understanding the sudoers Configuration The primary sudo configuration file is located at: /etc/sudoers Many Linux distributions also support separate configuration files under: /etc/sudoers.d/ The sudoers policy defines which users or groups can execute commands, which account those commands run as, and whether authentication is required. For example, a common Ubuntu configuration contains a rule similar to: %sudo ALL=(ALL:ALL) ALL This rule means: Component Description %sudo Members of the sudo group ALL Any host covered by the policy (ALL:ALL) Commands may run as any user and group ALL Any command is permitted On RHEL-based distributions, the administrative group is commonly named wheel instead of sudo. These configurations grant broad administrative access. That may be appropriate for trusted system administrators, but application operators and automation accounts often need fewer privileges. Security recommendation: Grant users access only to the administrative commands required for their responsibilities. 1. Edit sudoers Safely Using visudo Avoid editing /etc/sudoers directly with ordinary text editors. A configuration error can prevent sudo from authorizing commands. This becomes a serious problem when sudo is the only way to obtain root privileges. Instead, use: sudo visudo The visudo utility checks the configuration syntax before accepting changes. It also protects against conflicting edits. For custom rules, use a dedicated file: sudo visudo -f /etc/sudoers.d/90-webops This separates your custom rules from the main configuration. When creating sudoers files: Keep the files owned by root. Use restrictive permissions, normally 0440. Avoid periods and trailing ~ characters in filenames because sudoers directory processing skips these names. Keep an existing administrative session available until you verify the changes. You can check permissions with: sudo ls -l /etc/sudoers.d/ After editing, validate the complete configuration: sudo visudo -c A successful check confirms that the configuration passed syntax validation. It does not guarantee that every permission rule matches your intended security policy. 2. Grant Access to Specific Administrative Commands Consider a server hosting an NGINX application. A developer may need permission to reload NGINX after a deployment. Granting unrestricted sudo access for this task would provide far more authority than necessary. Instead, create a dedicated group: sudo groupadd webops Add the appropriate user: sudo usermod -aG webops alice The user must establish a new login session for the updated group membership to take effect. Next, create a policy: sudo visudo -f /etc/sudoers.d/90-webops Add: %webops ALL=(root) /usr/bin/systemctl reload nginx.service This allows members of webops to execute the specified NGINX reload command as root. For example: sudo systemctl reload nginx.service The rule does not authorize arbitrary commands such as: sudo useradd testuser sudo apt install nginx sudo systemctl restart ssh.service Unless another sudoers rule permits those operations, they will be denied. To inspect the user’s effective sudo permissions, log in as that user and execute: sudo -l Remember that sudoers restrictions are only one part of access control. A user who can modify NGINX configuration files, service units, or executable scripts used by a privileged service may be able to exercise greater privileges indirectly. Protect those files separately. 3. Control How Long sudo Remembers Authentication When you execute sudo, the system normally asks for your password. After successful authentication, sudo may temporarily remember your credentials. This allows subsequent administrative commands to run without another password prompt. The timestamp_timeout option controls this authentication period. For example: Defaults:%webops timestamp_timeout=2 This configures a two-minute authentication timeout for members of the webops group. For environments that require authentication every time, use: Defaults:%webops timestamp_timeout=0 A zero timeout requires fresh authentication for password-protected sudo commands. You can also invalidate your existing authentication timestamp manually: sudo -k The next sudo command requiring authentication will prompt for your password. Another setting, passwd_timeout, controls how long sudo waits while displaying a password prompt: Defaults passwd_timeout=1 This example allows one minute to complete password entry. These settings serve different purposes: Option Purpose timestamp_timeout Controls how long authentication remains valid passwd_timeout Controls how long sudo waits for password input passwd_tries Controls the number of authentication attempts For shared administrative workstations and sensitive servers, consider shorter authentication timeouts. The appropriate values depend on your security requirements and operating procedures. 4. Restrict Environment Variables and Command Paths Environment variables can influence how applications execute. For example, the PATH variable determines where the operating system searches for commands when an absolute executable path is not provided. If privileged commands inherit an unsafe environment, unexpected applications or libraries might be used. The following setting instructs sudo to construct a restricted environment: Defaults env_reset This option is already enabled by default on most modern sudo installations. You can also define a controlled executable search path: Defaults secure_path="/usr/sbin:/usr/bin:/sbin:/bin" This example uses standard system binary directories. Before applying it, verify that the required administrative tools and their dependencies are compatible with your selected paths. Some installations use additional directories. You can inspect your user’s current path with: echo "$PATH" You can also locate a command: command -v systemctl For sudoers command restrictions, prefer explicit executable paths instead of relying on command lookup. Security recommendation: Do not disable env_reset globally simply to fix an application that requires a particular environment variable. Investigate the requirement and allow only the necessary variables. 5. Isolate Privileged Commands with a Pseudo-Terminal A terminal provides the input and output interface for interactive commands. Under certain circumstances, a malicious privileged program may attempt to interfere with the invoking user’s terminal session. The use_pty setting makes sudo execute commands in a separate pseudo-terminal when sudo itself is attached to a terminal. Enable it with: Defaults use_pty Some modern sudo installations already enable this option by default. A separate pseudo-terminal provides additional isolation between the privileged command and the user’s terminal. However, use_pty does not prevent every form of privilege abuse. It also has no effect when sudo is invoked without an attached terminal. Should you enable requiretty? Another option is: Defaults requiretty This requires users to invoke sudo from an actual terminal. Although it can restrict some noninteractive sudo usage, it may also interfere with automation, remote command execution, and scheduled maintenance. Do not enable requiretty globally without reviewing these workflows. For most modern server environments, use_pty is the more practical setting to evaluate. 6. Record Administrative Activity Knowing which administrative commands were executed is useful during troubleshooting and security investigations. By default, sudo records authorization events through the system’s configured logging mechanism, commonly syslog. You can configure an additional dedicated destination for sudo event records using: Defaults logfile="/var/log/sudo-events.log" To include the hostname and year in file-based records: Defaults log_host, log_year This can help administrators identify activity when reviewing records from multiple servers. Depending on your Linux distribution and logging configuration, sudo events may also be accessible through system logs. For example: sudo journalctl -t sudo Or inspect the configured dedicated log: sudo tail -n 50 /var/log/sudo-events.log A sudo event record may include details such as: The account that invoked sudo. The command submitted. The terminal associated with the session. The target account. The working directory. Whether the action was permitted or denied. Important: Ordinary sudo event logging does not record every command executed inside a privileged interactive shell. For example, after an administrator enters a root shell, the individual commands executed inside that shell may not each generate a separate sudo authorization record. For security monitoring, combine sudo logging with appropriate operating system audit facilities and centralized log collection. Also configure access restrictions, log rotation, and retention policies for any additional log files. 7. Capture Privileged Command Output Sudo supports recording input and output from privileged command sessions. This can provide useful evidence when investigating administrative activity or troubleshooting unexpected changes. For example, to enable output recording for the webops group: Defaults:%webops log_output When this setting is active, sudo can record command output in its I/O logging directory. The default location is commonly: /var/log/sudo-io/ You can review available recorded sessions with: sudo sudoreplay -l The sudoreplay utility can replay recorded terminal sessions when the necessary I/O data exists. What about recording keyboard input? Sudo also supports: Defaults log_input However, enabling input logging requires careful consideration. Interactive programs may receive sensitive information, including credentials or other confidential values. Recording that input can create an additional security and privacy risk. For production systems, do not enable unrestricted input recording without an established security requirement, protected log storage, and appropriate retention controls. Even output recording may capture secrets returned by administrative commands. Use sudo I/O logging selectively and protect the recorded data. 8. Configure Restricted Passwordless sudo for Automation Automated deployment systems sometimes need to execute privileged commands without an interactive password prompt. For example, a deployment account might reload NGINX after publishing an application. A restricted sudoers rule could be: deploybot ALL=(root) NOPASSWD: /usr/bin/systemctl reload nginx.service This allows the deploybot account to execute the specified reload command without entering a password. It does not grant passwordless access to all administrative commands. Avoid rules such as: deploybot ALL=(ALL) NOPASSWD: ALL This grants extensive privileges to an automation account. If the account is compromised, those privileges can be abused. When configuring passwordless sudo: Restrict permissions to specific executable paths and arguments. Protect automation credentials and SSH keys. Review access to privileged scripts, configuration files, and systemd unit files. Monitor the account’s administrative activity. Remove permissions when the automation no longer needs them. Also remember that restricting sudo to a specific command does not automatically make that command safe. An authorized operation may still provide a path to additional privileges if it executes writable scripts or processes untrusted configuration files. 9. Apply Different sudo Settings to Different Users Not every Linux account needs the same administrative policy. Sudo supports scoped Defaults settings. For example: # General settings Defaults env_reset Defaults use_pty # Authentication policy for web operators Defaults:%webops timestamp_timeout=2 # Output logging for web operators Defaults:%webops log_output The first two directives apply generally. The remaining directives target members of the webops group. Other supported scopes include individual users, hosts, commands, and target execution accounts. This allows you to establish separate policies for different responsibilities. For example, system administrators may need broad administrative authority, while application support personnel may only need permission to reload a specific service. Review the complete policy when multiple rules apply to the same user. An account may receive permissions from several sudoers files or group memberships. 10. Validate and Test Your sudo Configuration Configuration validation should be part of every sudoers change. First, check the syntax: sudo visudo -c Next, inspect the permitted commands for the account being tested: sudo -l For accounts with restricted permissions, test both authorized and unauthorized operations. For example, a webops user might be permitted to run: sudo systemctl reload nginx.service But should not be able to execute an unrelated privileged command such as: sudo useradd testuser Perform negative permission tests in a safe environment. Never assume a command will be denied before checking the effective policy. If a rule does not work as expected, review: Whether the account belongs to the correct group. Whether the user has logged in again after a group membership change. Whether the executable path and arguments match the sudoers rule. Whether another sudoers rule provides additional permissions. Whether the configuration file is actually included. Whether sudoers reports ownership, permission, or syntax errors. You can inspect the installed sudo version with: sudo -V Behavior and supported options may differ between sudo versions. Avoid locking yourself out When changing sudo permissions on a remote production server, keep an existing administrative session active until verification is complete. If sudo access fails, you may need console access or another authorized recovery method. On VPS platforms, confirm the availability of a recovery console before changing critical authentication policies. Common sudoers Configuration Mistakes Some sudo configuration practices create risks even when the syntax is valid. Mistake Why it matters Granting NOPASSWD: ALL broadly Exposes unrestricted privileged access if the account is compromised Allowing unrestricted shells or script interpreters May effectively provide root-level control Editing sudoers without validation Can break administrative access Ignoring executable arguments May allow operations beyond the intended task Allowing modifications to privileged scripts Can bypass restrictions on permitted commands Recording sensitive input without controls May expose confidential information in logs Assuming command logs capture entire root sessions Leaves gaps in investigation records Using requiretty without testing automation May break unattended administrative tasks Remember that sudo is an authorization mechanism. It is not a complete security boundary against a trusted administrator who already has unrestricted root access. A Practical sudoers Security Checklist Before deploying a sudo policy on a production system, verify the following: Administrative privileges are assigned according to actual responsibilities. Application and automation accounts have restricted permissions. Configuration changes are performed through visudo. Sudoers files have appropriate ownership and permissions. Authentication timeouts meet your security requirements. Privileged commands execute with a controlled environment. Sudo event logs are available for investigation. Any I/O recordings have access controls and retention policies. Both permitted and denied operations have been tested. A recovery method exists if administrative access is lost. Final Thoughts The sudoers configuration is a fundamental part of Linux access management. A secure sudo policy starts by identifying which administrative operations each account actually needs. From there, administrators can configure authentication, control the execution environment, and record relevant activities. For production Linux servers, focus on three priorities: Restrict administrative permissions. Avoid granting root access when a specific command is sufficient. Keep administrative activity visible. Configure logging appropriate for troubleshooting and incident response. Validate configuration changes. Test permissions before relying on them in production. A carefully maintained sudoers configuration reduces unnecessary privileges and makes administrative access easier to review. References and Further Reading The configuration options and behaviors discussed in this guide are documented in the following resources: sudoers(5), Linux Manual Page visudo(8), Linux Manual Page Ubuntu sudoers Documentation Ubuntu Community Guide to sudoers