Sudo with a fingerprint on Linux

To use a fingerprint for sudo on Linux, enroll a supported local reader with fprintd, then add pam_fprintd to sudo’s PAM authentication stack while retaining the password path. If the laptop has no reader, that setup cannot create one: phone approval uses a separate sensor and a different PAM integration.

Check the reader before changing sudo

Start with the hardware, rather than a login settings toggle. Run the following as your ordinary desktop user. Keep the output so you can distinguish a missing executable from a daemon that cannot find a usable sensor.

lsusb
fprintd-list "$USER"

lsusb lists USB devices; it does not prove that a fingerprint driver supports them. Compare the reader’s vendor and product ID with the libfprint supported-device list. That list describes the development version, so check which libfprint release your distribution actually packages. A laptop model name alone is too broad a compatibility test.

If no usable device appears, resolve that before editing authentication. A PAM line cannot repair a disconnected sensor or supply missing hardware support. On a managed work machine, ask its administrator before changing the authentication policy; the examples below are for a personal Linux installation.

Install the local fingerprint components

Ubuntu and Debian

Install the daemon and PAM module from your distribution’s configured repositories. These commands apply to apt-based installations; do not paste them into an Arch terminal.

sudo apt update
sudo apt install fprintd libpam-fprintd

Ubuntu supplies the module in libpam-fprintd. The distribution’s pam-auth-update utility can select packaged authentication profiles, but those shared profiles affect services beyond sudo. For a sudo-only change, inspect /etc/pam.d/sudo instead of enabling a shared fingerprint profile blindly.

Arch Linux

On Arch, the fprintd package includes pam_fprintd.so. Install it through a normal full system upgrade, rather than mixing a newly synchronized package with an otherwise outdated system.

sudo pacman -Syu fprintd

Other distributions may use different package names or policy tools. Read their packaged PAM configuration before adapting either example. Installing a package and deciding which services should accept fingerprints are separate steps.

Enroll and verify your own fingerprint

Run enrollment without sudo so the target identity is your desktop account. Follow the sensor prompts, then test recognition outside sudo. The fprintd command manual documents the optional finger selection and username arguments.

fprintd-enroll -f right-index-finger
fprintd-list "$USER"
fprintd-verify -f right-index-finger

Do not proceed until verification succeeds for the account that will run sudo. If enrollment exists but matching fails, work on that failure first. Testing PAM at the same time would introduce a second unknown and make the resulting prompt harder to interpret.

Add the rule without losing a recovery path

Open a root shell in one terminal and leave it open while testing from a different, ordinary-user terminal. This gives you a way to restore the file if you make an authentication mistake. Save a copy before opening the editor.

sudo -s
# Leave this root shell open; use another terminal for tests.
cp -a /etc/pam.d/sudo /etc/pam.d/sudo.before-fingerprint
# In the ordinary-user terminal:
sudoedit /etc/pam.d/sudo

In a conventional sudo stack, place this line before its existing password-authentication include. Preserve the existing password, account and session rules. This is an addition to the file, not a replacement for its contents.

auth sufficient pam_fprintd.so max-tries=3 timeout=10

The pam_fprintd manual documents these options. Here, three attempts and a ten-second timeout are explicit configuration choices. Fingerprint and password prompts run sequentially in this PAM path; typing a password while the reader is waiting does not create simultaneous authentication.

A successful sufficient rule can finish authentication if no earlier required module has failed. Its failure lets processing continue. Review the PAM control semantics before changing order: putting a shortcut above a mandatory authentication check can defeat the policy you meant to retain. Do not use this example to bypass an organization’s required second factor.

Test success, timeout and password fallback

In the ordinary-user terminal, invalidate sudo’s cached authentication before each trial. Otherwise a recent successful sudo can make a broken reader setup look functional.

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

First approve with the enrolled finger. Then repeat the commands and leave the sensor untouched; after the configured wait, check that the password prompt still works. The sudo manual describes -k. A successful root identity check prints 0; it does not prove that every other PAM service is configured correctly.

If either path fails, restore the saved file from the root shell you kept open, then retest ordinary password sudo. Close that root shell only after you have checked both paths.

cp -a /etc/pam.d/sudo.before-fingerprint /etc/pam.d/sudo

Keep the original backup until you have also checked a new terminal session. Record the one line you added and the reason for its placement, so a later package update is easier to review. Avoid copying your entire PAM file to another distribution: its includes may have different names and policy responsibilities. Repeat the fallback check after any subsequent authentication change rather than relying on the first successful scan.

When the laptop has no reader

Stop looking for a pam_fprintd setting that redirects scans from Android. The local-reader recipe above and a phone approval system are different arrangements. Phone approval needs software on both devices and an authenticated request-and-response path; installing fprintd alone does not establish that path.

The phone route offered here requires Linux sudo using PAM, a systemd user session, Android 10 or newer with a fingerprint sensor, and both devices on the same Tailscale network. The phone displays the command and signs approval; the laptop checks it against the enrolled public key. You install the helper with root access and add its PAM rule yourself. A missing phone or failed approval returns to the password prompt, rather than granting access.

No reader in the laptop?

For a Linux laptop without a reader, a phone approval system moves the scan to Android rather than emulating a local sensor. Finger requires Tailscale, PAM setup and an enrolled phone; unsuccessful approvals fall back to the password prompt. See Finger requirements and approval workflow, or browse the current software catalogue.