How to Configure Passwordless Sudo in Linux

You can configure passwordless sudo in Linux with the NOPASSWD tag in a sudoers rule. The safest approach is to allow only the exact commands an administrator or automation account needs, instead of granting password-free access to every root command.

This guide works with traditional sudo on Ubuntu, Debian, RHEL, Rocky Linux, AlmaLinux, Fedora, and CentOS. Newer Ubuntu releases may use sudo-rs, so always check the local manual and validate the installed implementation.

What does passwordless sudo mean?

Normally, sudo asks an authorised user to confirm their identity with a password. A sudoers rule tagged NOPASSWD removes that prompt for the commands covered by the rule.

It does not mean the account has no login password. It also does not replace SSH authentication. It changes only the selected sudo authorisation flow.

Understand the security risk first

Passwordless sudo is useful for tightly controlled automation and a few routine operational commands. It also removes an authentication barrier. If the account or its SSH key is stolen, an attacker can run every command permitted by the rule without another secret.

A rule like this gives unrestricted root power without a password:

username ALL=(ALL:ALL) NOPASSWD: ALL

Avoid it for normal users. Prefer one or more exact executable paths, and make sure the user cannot edit those executables or their configuration in a way that produces a root shell.

Check the username and existing sudo access

whoami
id
sudo -l

Ubuntu and Debian commonly authorise administrators through the sudo group. RHEL-based distributions commonly use wheel. Group membership alone does not tell you which individual commands are allowed, so sudo -l is the better check.

Find the exact command path

Sudoers command rules should use absolute paths:

command -v systemctl
command -v journalctl

Common results are /usr/bin/systemctl and /usr/bin/journalctl, but confirm them on the actual machine.

Create a passwordless sudo rule safely

Keep custom rules in /etc/sudoers.d/ rather than editing the main file directly. Open a new rule with syntax checking:

sudo visudo -f /etc/sudoers.d/web-operator

Allow the user deploy to restart only the Nginx service:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx.service

This rule means:

• deploy: the account receiving permission.
• ALL: the rule applies on all hosts where this sudoers file is installed.
• (root): the command may run as root.
• NOPASSWD:: no sudo password prompt for the following command.
• The remaining text: the exact allowed command and argument.

Save and exit. visudo checks syntax before installing the change.

Set secure permissions on the rule

sudo chown root:root /etc/sudoers.d/web-operator
sudo chmod 0440 /etc/sudoers.d/web-operator

Do not let the authorised user modify the sudoers file. A writable rule would let that user grant themselves more access.

Validate all sudoers files

sudo visudo -c

Do not log out of the current administrator session if validation reports an error. Repair the rule with visudo -f.

Test passwordless sudo without a cached password

Open a second login session as the target user. Clear that user’s cached sudo timestamp:

sudo -k

Test the exact allowed command non-interactively:

sudo -n /usr/bin/systemctl restart nginx.service

The -n option prevents sudo from prompting. It succeeds only when the rule allows the command without authentication. Then confirm that an unrelated command is still refused or requires authentication:

sudo -n /usr/bin/id

Keep the original administrator session open until both positive and negative tests behave as expected.

Allow several exact commands

Separate commands with commas:

deploy ALL=(root) NOPASSWD: \
    /usr/bin/systemctl restart nginx.service, \
    /usr/bin/systemctl reload nginx.service, \
    /usr/bin/systemctl status nginx.service

Line continuation and whitespace rules matter in sudoers. Use visudo and check the local sudoers manual when formatting a multi-line rule.

Use a command alias for readable rules

Cmnd_Alias NGINX_OPERATIONS = \
    /usr/bin/systemctl restart nginx.service, \
    /usr/bin/systemctl reload nginx.service, \
    /usr/bin/systemctl status nginx.service

deploy ALL=(root) NOPASSWD: NGINX_OPERATIONS

A command alias improves readability but does not add security by itself. Review every command in the alias.

Allow a group instead of one user

A percent sign identifies a Unix group:

%webops ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx.service

Add only approved people to the group. Our Linux group-management guide explains membership and verification.

Arguments in sudoers rules matter

An exact command with exact arguments is narrower than allowing the executable with any argument. This rule is limited to one service action:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx.service

This broader rule may permit the user to manage many services:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl

Avoid broad interpreters, editors, pagers, shells, package managers, container tools, and commands with shell-escape features. Many apparently harmless programs can execute another command or modify root-owned files.

Do not place shell operators inside a sudoers command

Operators such as |, >, &&, and command substitution are processed by the user’s shell, not by sudo as part of an executable path. If automation requires several actions, create a root-owned wrapper with fixed behaviour, review it carefully, and allow only that wrapper.

The wrapper and every file it executes must not be writable by the unprivileged user.

Passwordless sudo for a script

Suppose a reviewed script is stored at /usr/local/sbin/reload-example. Protect it:

sudo chown root:root /usr/local/sbin/reload-example
sudo chmod 0755 /usr/local/sbin/reload-example

Then authorise the exact path:

deploy ALL=(root) NOPASSWD: /usr/local/sbin/reload-example

Do not let the script load user-controlled code, configuration, environment files, or paths as root unless that input is strictly validated.

Require a password for other commands

The PASSWD tag can change the behaviour for later commands in the same list:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx.service, \
    PASSWD: /usr/bin/systemctl restart ssh.service

Rule interaction can become complex when multiple files, groups, and tags match the same user. Always verify the effective policy with:

sudo -l -U deploy

Remove passwordless sudo access

Delete the specific custom file from an active administrator session:

sudo rm /etc/sudoers.d/web-operator
sudo visudo -c

If the file contains other required rules, edit it with sudo visudo -f /etc/sudoers.d/web-operator instead. Test from a second session after removal.

Recover from a sudoers syntax mistake

If another administrator session is still open, repair the file with visudo. If sudo is completely broken, use authorised console access, recovery mode, or the hosting provider’s rescue environment.

Avoid editing /etc/sudoers with an ordinary text editor. visudo exists to lock the file and catch syntax errors before they remove administrative access.

Common passwordless sudo problems

Sudo still asks for a password

Check the exact username, command path, arguments, host match, and rule order. Run:

sudo -l
sudo visudo -c

The command used for testing must match the sudoers entry.

The file in /etc/sudoers.d is ignored

Confirm that the main sudoers file includes the directory, that the filename is acceptable to the installed implementation, and that ownership and permissions are secure. Avoid filenames ending in ~ or containing a dot when compatibility with traditional sudo’s include rules matters.

sudo -n says a password is required

No matching NOPASSWD rule authorises that exact command. This is useful in automation because it fails instead of waiting for interactive input.

The restricted command still gives a root shell

The selected program probably has a shell escape, plugin, editable configuration, or argument that executes other commands. Remove the rule immediately and choose a narrower root-owned wrapper or different design.

Security checklist

• Prefer exact commands and arguments.
• Use absolute executable paths.
• Protect rules and wrappers with root ownership.
• Validate every change with visudo -c.
• Test allowed and denied commands in a second session.
• Protect SSH keys and restrict login sources.
• Review sudo rules and group membership regularly.
• Remove access when automation or staff roles change.

Passwordless sudo should be one small part of a broader Linux server hardening plan.

Frequently asked questions

Is NOPASSWD sudo safe?

It can be reasonable for a trusted account and a small set of carefully reviewed commands. Unrestricted NOPASSWD: ALL greatly increases the impact of account compromise.

Should I edit /etc/sudoers directly?

Use visudo. A dedicated file under /etc/sudoers.d/ usually makes a custom rule easier to test, review, and remove.

Does NOPASSWD disable the user’s login password?

No. It affects authentication for matched sudo commands, not the account’s SSH, console, or desktop login password.

Why use sudo -n when testing?

Non-interactive mode fails immediately if a password would be required. This makes the result clear and prevents automation from hanging at a prompt.

Official references

• sudoers policy manual
• visudo command manual
• Ubuntu Server user management

You now know how to configure passwordless sudo in Linux without immediately giving away unrestricted root access. Start with one exact command, validate it, test both permitted and denied behaviour, and expand the rule only when the operational need is clear.