Passwordless sudo on Linux: when to use it

Passwordless sudo on Linux usually means a sudoers rule tagged NOPASSWD, which lets matching commands run without an authentication prompt. Fingerprint approval through PAM is different: you still authenticate, and a rule such as [success=done default=ignore] can retain password fallback when the fingerprint path fails.

Decide which prompt you want to remove

Start by distinguishing an unattended task from an interactive administrator session. A backup job cannot touch a fingerprint reader while you are away. A person sitting at a laptop may want an approval gesture instead of typing. Those requirements lead to different policies, even though both are sometimes called “passwordless.”

Also check whether you are seeing sudo’s authentication cache. A second command can run without another prompt because an earlier authentication remains valid under your current policy. That is not evidence that a NOPASSWD rule exists, and it does not prove a newly configured fingerprint path works.

id -un
sudo -l
sudo -k

Read the sudo command manual for listing privileges, invalidating cached authentication with -k and noninteractive testing with -n. Test deliberately from your ordinary user account; an already privileged root shell cannot tell you what that account will be asked to authenticate.

What NOPASSWD grants

The following broad example is for reading, not a recommended desktop configuration. Here, alice is an example username, not a special sudo keyword.

alice ALL=(ALL:ALL) NOPASSWD: ALL

This permits Alice to run any matching command as any user or group without authenticating. Someone who can run commands as Alice can use that permission too. On a personal laptop, broad NOPASSWD removes the authentication barrier between compromise of your user session and root access. Convenience is the benefit; loss of that checkpoint is the trade-off.

Scope is the important decision. If a job needs one fixed operation, granting every command gives it far more authority than the job describes. Do not regard an editor, shell or general scripting interpreter as a narrow operation merely because the sudoers line contains one executable name.

Build a narrow, inspectable example with visudo

Use a harmless identity query to learn the mechanism before granting a useful privileged operation. First check the executable path on your machine. The example below uses /usr/bin/id; adapt it if your system reports a different absolute path.

command -v id

Keep a root shell open for recovery, then use visudo to create a dedicated include file from another terminal. Confirm that your main sudoers file includes /etc/sudoers.d. Choose an otherwise unused filename without a dot, since sudoers directory inclusion skips certain names.

sudo -s
# Keep this root shell open; in a second terminal run:
sudo visudo -f /etc/sudoers.d/90-local-id

Put this line in that file, replacing alice with the account printed by id -un. It grants the exact identity-query arguments as root, rather than granting arbitrary commands.

alice ALL=(root) NOPASSWD: /usr/bin/id -u

The visudo manual documents its editor and syntax checks. Do not force-save a syntax error. After saving, validate the whole policy as well as the individual file so you see problems in the included configuration.

sudo visudo -cf /etc/sudoers.d/90-local-id
sudo visudo -c

The sudoers manual is the reference for command matching, tags and include ordering. Other matching rules can affect the outcome; do not assume the most specific-looking line automatically wins. Inspect the effective policy instead of repeatedly appending broader grants.

Test the grant and remove the learning example

From the ordinary-user terminal, invalidate the timestamp and request the exact operation without allowing a prompt. For this example, successful execution prints 0, the numeric root identity.

sudo -k
sudo -n /usr/bin/id -u

A failure does not justify changing the rule to ALL. Check the account, executable path, argument spelling and later matching entries. If the operation succeeds, consider what that establishes: the rule permits the identity query without authentication. It says nothing about whether an unrelated maintenance command would be safe to delegate.

Once you understand the example, remove its dedicated file from the root shell you retained and check the configuration there. Do this only for the example file you created; do not remove somebody else’s policy.

rm /etc/sudoers.d/90-local-id
visudo -c

How the PAM fingerprint pattern differs

For interactive approval with a supported local reader, an authentication line can use this control expression before the existing password-authentication include. The reader must already enroll and verify successfully.

auth [success=done default=ignore] pam_fprintd.so max-tries=3 timeout=10

Under PAM’s documented control syntax, success can finish this authentication stack if no previous nonignored failure prevents it. Other return values are ignored for this rule, leaving later rules to decide. That is why keeping a working password stack below it matters: ignoring a failed fingerprint attempt is not itself a grant of access.

Placement can skip later authentication checks, so do not insert this above mandatory multi-factor controls. Preserve account and session policy, keep a recovery shell, and test both successful approval and the unavailable-reader case. NOPASSWD skips the authentication challenge for the permitted command; this pattern offers another way to satisfy it.

Choose the policy for the task

For an unattended task, specify the smallest necessary operation and review everything it can execute or modify. A root-run script writable by the unprivileged caller defeats the intention of a short command list. Treat delegated authority as a capability to review, not a typing preference.

For interactive sudo, local fingerprint or phone approval can keep an authentication event while avoiding password entry. It is not automatically two-factor authentication when either fingerprint approval or a password can independently succeed. Existing sudo timestamp policy can also reuse authentication, so do not promise that any of these setups requires a fresh touch for every command.

Keep approval in an interactive workflow

If your goal is avoiding password entry while retaining an approval step, Finger uses an enrolled Android phone to sign sudo approvals. It is an interactive Linux + Android workflow over Tailscale, with password fallback; it does not supply unattended NOPASSWD execution. See Finger requirements and approval workflow, or browse the current software catalogue.