Passwordless sudo for one command: sudoers guide with visudo

To allow passwordless sudo for a single command, create a file in /etc/sudoers.d with visudo -f and add a rule such as user ALL=(root) NOPASSWD: /absolute/path arguments. The absolute path and fixed arguments restrict the permission to that exact command. NOPASSWD: ALL, by contrast, amounts to handing out root without a password.

A NOPASSWD sudoers rule for one command: full example with visudo

The rule is created with visudo -f on a new file inside /etc/sudoers.d, never by opening the file in an arbitrary editor. The example uses a deploy user that should only reload nginx after a release:

sudo visudo -f /etc/sudoers.d/deploy-nginx

File contents:

# deploy may reload nginx without a password, and nothing else
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl reload nginx

Check the path first with command -v systemctl. Depending on the distribution it may live in /usr/bin or /bin, and the rule only matches the exact path. Then validate and test:

sudo visudo -c
sudo -l -U deploy
sudo -n /usr/bin/systemctl reload nginx

visudo -c checks the syntax of every sudoers file. sudo -l -U deploy lists what that user may run. sudo -n, run as deploy, fails instead of prompting for a password, so it tells you whether NOPASSWD actually applies.

Why use visudo and /etc/sudoers.d instead of hand-editing /etc/sudoers

visudo locks the file while you edit it and checks the syntax before saving. If it finds an error, it warns you and lets you fix it. A broken /etc/sudoers can leave sudo unusable, and on a server without a root password that means a trip to the recovery console.

• One file per permission. Deleting the file revokes the rule without touching anything else.
• Kept apart from the main file. Changes a package ships for /etc/sudoers don't collide with yours.
• No dots in file names. sudo skips files in /etc/sudoers.d whose name contains a dot or ends in ~: deploy-nginx is read, deploy.conf is not.
• Owned by root, mode 0440. Verify with ls -l /etc/sudoers.d; if you copied the file from elsewhere, fix it with chown root:root and chmod 0440.

Absolute paths in NOPASSWD: why sudoers requires them and how to pin arguments

sudoers requires the full path of the executable: a bare name such as systemctl is a syntax error in visudo. The absolute path stops anyone from dropping a different binary with the same name into a directory on their PATH and running it as root.

Arguments are the other half of the control:

1. No arguments in the rule (/usr/bin/systemctl): any arguments are allowed, including stopping or editing any service.
2. Exact arguments (/usr/bin/systemctl reload nginx): only that command line.
3. An empty "" (/usr/local/bin/backup ""): the command is accepted only with no arguments.
4. Wildcards (/usr/bin/systemctl restart *): the asterisk also matches spaces and lets through more arguments than intended. Avoid them.

Why not NOPASSWD: ALL in sudoers: comparing the risks

With NOPASSWD: ALL, any process running as your user —a compromised script, a malicious dependency, a stolen SSH key— gets root through sudo -n with no interaction at all. A scoped rule shrinks that prize to a single command.

A scoped rule is still dangerous if the allowed command can spawn a shell or run other programs: editors such as vi, pagers such as less, find with -exec, or a script the user can modify. If you allow a script, it must be owned by root and writable by nobody else. To edit protected files, use sudoedit, which works on a copy with the user's permissions. The NOEXEC tag can stop a command from launching others, but it doesn't work with every binary.

Rule order in sudoers: the last match wins

When several rules match the same user and command, sudo applies the last one. If /etc/sudoers.d is included at the end of /etc/sudoers, your NOPASSWD rule sits after the general admin-group rule and takes precedence. If a later line requires a password for that user, it overrides your rule and sudo -n keeps failing. sudo -l prints the entries in order, which makes the conflict easy to spot.

Editing sudoers from your phone with termi1 without locking yourself out

visudo opens the system's configured editor, often vi or nano, and both need Esc, Ctrl and the arrow keys. termi1's own keyboard has the keys the system keyboard hides, plus an fn layer with F1–F12, PgUp/PgDn, Home and End.

• Keep a spare root shell. Open sudo -i in another tmux window before touching sudoers; if something breaks, you still have root to fix it.
• Keep the session alive. With Mosh, termi1 holds the session when you switch from wifi to mobile data, and tmux keeps whatever you left running.
• Review before running. termi1's AI turns a sentence like “let deploy reload nginx without a password” into a command typed at the prompt without pressing Enter. On connections tagged as production, Production Guard holds back anything that deletes, stops or changes something before it reaches the prompt.

SSH keys can be generated on the phone and the private key never leaves the device. Read more about the SSH terminal for your phone, download termi1 for iPhone or visit the technical support centre.

Frequently asked questions

Where does NOPASSWD go in a sudoers rule?

NOPASSWD goes in a sudoers rule right before the command, after the colon: deploy ALL=(root) NOPASSWD: /usr/bin/systemctl reload nginx. The tag carries over to later commands on the same line, so keep that line limited to the one command you want to allow without a password.

Why is my file in /etc/sudoers.d not working?

A file in /etc/sudoers.d usually fails for one of three reasons: its name contains a dot or ends in ~, a later rule requires a password and overrides it, or the command path doesn't match exactly. Check with sudo visudo -c and sudo -l run as that user.

What happens if I save sudoers with a syntax error?

Saving sudoers with a syntax error can leave sudo broken for every user. visudo prevents this because it checks the syntax before saving and reports the error. If you edit with another editor and break the file, you will need an already open root shell or the recovery console.

Is it safe to give NOPASSWD to my own script?

Giving NOPASSWD to your own script is only safe if the script is owned by root and no other user can modify it. If the user holding the sudo permission can edit the script, they can add any command and run it as root without a password. Always use absolute paths and fixed arguments.