Linux Mint 21/22 MATE: FIDO2 + PIN Login Walkthrough

1. What are FIDO U2F and FIDO2?

FIDO U2F and FIDO2 are authentication standards from the FIDO Alliance that use public-key cryptography instead of reusable shared secrets. The private credential remains on the authenticator, such as a hardware security key, while the relying system stores only public registration data.

FIDO U2F

FIDO U2F, or Universal 2nd Factor, is the older model. It is primarily used as a second factor: the user enters a normal password first, then proves possession of the hardware token by touching or activating it.

FIDO2

FIDO2 is the newer model. It supports stronger authenticator behavior, including PIN-backed and potentially passwordless authentication. Depending on the token and software stack, FIDO2 can support a flow where the security key effectively replaces the account password.

2. Authentication design used by this guide

This guide uses a group-gated local policy:

• Users in fido-login authenticate with FIDO2 token PIN + physical touch only.
• Users not in fido-login, such as a controlled breakglass/local-admin account, remain password-only.
• FIDO users do not fall back to Unix password if FIDO fails.

auth [success=ignore default=1] pam_succeed_if.so quiet user ingroup fido-login
auth [success=done default=die] pam_u2f.so authfile=/etc/security/u2f_keys cue pinverification=1 userverification=0

3. Assumptions, placeholders, and safety preconditions

Replace these placeholders before running commands:

• Keep a root-capable terminal or TTY recovery path available while testing.
• Do not modify /etc/pam.d/login in this walkthrough. Console TTY password login is your recovery path.
• Back up each PAM file before editing it. The commands below include backup steps.
• Do not close your working session until LightDM, sudo, and screen unlock have all been tested.

4. Command style in this guide

Command blocks are copy-pasteable and do not include shell prompt characters. The label above each block tells you whether it is intended for a normal user shell, a sudo command, or a PAM snippet.

VirtualBox: enable USB passthrough for the FIDO token

If you are running Linux Mint inside VirtualBox, the FIDO token must be explicitly passed through to the VM before the guest OS can see it. VirtualBox does not pass USB devices to a VM by default.

1. With the VM powered off, open VirtualBox Manager and select your VM.
2. Click Settings → USB.
3. Make sure Enable USB Controller is checked. Choose USB 2.0 (EHCI) or USB 3.0 (xHCI) depending on your host and token. The xHCI controller requires the VirtualBox Extension Pack.
4. Click the Add USB filter icon (plug with a green plus). Insert the FIDO token into the host first so it appears in the device list, then select it. This creates a filter that automatically routes that token to the VM whenever it is inserted.
5. Click OK and start the VM.
6. Once booted, insert the FIDO token and verify the guest sees it: Normal user shell

   lsusb
   fido2-token -L

   fido2-token -L should list a device path such as /dev/hidraw1: vendor model FIDO+U2F. If it returns nothing, confirm the USB filter is saved and the correct controller type is selected.

5. Install required packages

sudo apt update
sudo apt install libpam-u2f pamu2fcfg fido2-tools pamtester

6. Set or verify the FIDO2 PIN

fido2-token -L

Example output:

/dev/hidraw1: KEY-ID FIDO+U2F

fido2-token -I /dev/hidraw1

Set a PIN if needed:

fido2-token -S /dev/hidraw1

Change an existing PIN if needed:

fido2-token -C /dev/hidraw1

7. Pre-PAM FIDO2/PIN test

Before touching PAM, verify that the token accepts its PIN and requires physical presence.

rm -rf /tmp/fido2-login-test
mkdir -p /tmp/fido2-login-test
cd /tmp/fido2-login-test

echo "debian local login test challenge" | openssl sha256 -binary | base64 > cred_param
echo "localhost" >> cred_param
echo FIDO_USER >> cred_param
dd if=/dev/urandom bs=32 count=1 status=none | base64 >> cred_param

fido2-cred -M -t pin=true -i cred_param /dev/hidraw1 | fido2-cred -V -o cred

Expected behavior for a KEY-ID FIDO+U2F style token: enter the FIDO2 PIN, watch for the LED/button to flash, then press the token button. The command should return successfully and create cred.

ls -l cred
cat cred

If you intentionally enter a bad PIN, FIDO_ERR_PIN_INVALID is expected. If you run without -t pin=true and see FIDO_ERR_PIN_REQUIRED, rerun with -t pin=true.

cd
rm -rf /tmp/fido2-login-test

8. Create and populate the FIDO login group

The fido-login group is the selector. Members use FIDO2; non-members use password auth.

sudo groupadd --force fido-login
sudo usermod -aG fido-login FIDO_USER
id FIDO_USER
getent group fido-login

9. Create the central PAM mapping file

Use a central mapping file instead of ~/.config/Yubico/u2f_keys. This avoids encrypted-home and graphical-locker timing problems.

pamu2fcfg -N -u FIDO_USER > /tmp/u2f_keys-FIDO_USER
cat /tmp/u2f_keys-FIDO_USER

Expected: token PIN prompt, optional flashing/touch, and one mapping line beginning with FIDO_USER:.

sudo install -o root -g fido-login -m 0640 /tmp/u2f_keys-FIDO_USER /etc/security/u2f_keys
rm -f /tmp/u2f_keys-FIDO_USER
sudo python3 -c 'from pathlib import Path; p=Path("/etc/security/u2f_keys"); p.write_text(p.read_text().rstrip()+"\n")'
sudo ls -l /etc/security/u2f_keys
sudo grep "^FIDO_USER:" /etc/security/u2f_keys

Expected permissions:

-rw-r----- 1 root fido-login ... /etc/security/u2f_keys

Enroll a backup token

Insert the backup token, then append a second credential to the same user line.

sudo cp /etc/security/u2f_keys /tmp/u2f_keys-FIDO_USER.new
sudo chown FIDO_USER:fido-login /tmp/u2f_keys-FIDO_USER.new
chmod 0640 /tmp/u2f_keys-FIDO_USER.new
printf ':' >> /tmp/u2f_keys-FIDO_USER.new
pamu2fcfg -N -n >> /tmp/u2f_keys-FIDO_USER.new
sudo install -o root -g fido-login -m 0640 /tmp/u2f_keys-FIDO_USER.new /etc/security/u2f_keys
rm -f /tmp/u2f_keys-FIDO_USER.new
sudo python3 -c 'from pathlib import Path; p=Path("/etc/security/u2f_keys"); p.write_text(p.read_text().rstrip()+"\n")'
sudo ls -l /etc/security/u2f_keys

10. Create a shared PAM include file

Instead of copying the same FIDO logic into every PAM service, put it in one reusable include file.

sudo test -e /etc/pam.d/fido2-local-auth && sudo cp -a /etc/pam.d/fido2-local-auth /etc/pam.d/fido2-local-auth.bak || true
sudo tee /etc/pam.d/fido2-local-auth >/dev/null <<'EOF'
{{EMBED:config/fido2-local-auth}}
EOF

Use one of these include styles depending on the surrounding PAM file:

@include fido2-local-auth
@include common-auth

auth include fido2-local-auth
auth include common-auth

11. Test PAM with a standalone service

Create a temporary PAM service before editing LightDM, sudo, su, or screen-locker files.

sudo test -e /etc/pam.d/fido2-test && sudo cp -a /etc/pam.d/fido2-test /etc/pam.d/fido2-test.bak || true
sudo tee /etc/pam.d/fido2-test >/dev/null <<'EOF'
{{EMBED:config/fido2-test}}
EOF

sudo pamtester fido2-test FIDO_USER authenticate
sudo pamtester fido2-test BREAKGLASS_USER authenticate

Expected: FIDO_USER gets FIDO PIN + touch only. BREAKGLASS_USER gets password only.

If pamtester says “Authentication service cannot retrieve authentication info”

whoami
id FIDO_USER
getent group fido-login
sudo ls -l /etc/security/u2f_keys
sudo grep "^FIDO_USER:" /etc/security/u2f_keys
sudo cat /etc/pam.d/fido2-local-auth
sudo cat /etc/pam.d/fido2-test

12. Configure LightDM graphical login

Edit /etc/pam.d/lightdm, not /etc/pam.d/lightdm-greeter, for normal user login authentication.

sudo cp -a /etc/pam.d/lightdm /etc/pam.d/lightdm.bak
sudo editor /etc/pam.d/lightdm

Find the service’s existing password include, usually:

@include common-auth

Insert the shared FIDO include immediately above it. Preserve unrelated lines such as pam_nologin, pam_env, SELinux, limits, loginuid, and keyring lines.

# FIDO2 local authentication policy
@include fido2-local-auth

@include common-auth

Do not modify lightdm-greeter on the first pass

/etc/pam.d/lightdm-greeter normally permits the greeter process itself to start. It is not the normal user-authentication path.

auth      required pam_permit.so

Optional: prefer username-first graphical login

The group-gated PAM design needs to know the username before it selects the FIDO or password path. LightDM supports manual username entry when the greeter supports it. The greeter-hide-users and greeter-show-manual-login settings below are LightDM seat settings, honored by Slick Greeter as well as the GTK greeter.

sudo mkdir -p /etc/lightdm/lightdm.conf.d
sudo tee /etc/lightdm/lightdm.conf.d/50-manual-login.conf >/dev/null <<'EOF'
{{EMBED:config/50-manual-login.conf}}
EOF

Expected presentation:

Username:
Password/PIN:

Pre-logout LightDM PAM test

sudo pamtester lightdm FIDO_USER authenticate
sudo pamtester lightdm BREAKGLASS_USER authenticate

Slick Greeter prompt behavior

Verify on your install — not yet validated on Mint. On the GTK greeter (Debian XFCE), the greeter sometimes displays blank prompt lines for the FIDO/PAM conversation until Enter is pressed. Slick Greeter renders the PAM conversation differently, and its handling of a custom pam_u2f cue and PIN prompt has not been confirmed for this lab. When you test the greeter on Mint, note exactly what appears: whether the PIN prompt and the cue text (“FIDO users: enter token PIN, then touch token when it flashes”) are shown, whether you must press Enter first, and whether the token flashes on schedule. Record the observed flow so it can be documented for students.

13. Configure sudo

sudo cp -a /etc/pam.d/sudo /etc/pam.d/sudo.bak
sudo editor /etc/pam.d/sudo

Place the shared FIDO include immediately before @include common-auth.

session    required   pam_limits.so

@include fido2-local-auth
@include common-auth
@include common-account
@include common-session-noninteractive

sudo -k
sudo -v

13.1 Protect the sudo PAM configuration from package updates

Install an apt post-invoke hook that checks for the FIDO include after every apt invocation and re-adds it if a package upgrade removed it.

Step 1: Create the guard script.

sudo tee /usr/local/sbin/fido2-sudo-pam-guard >/dev/null <<'EOF'
{{EMBED:scripts/fido2-sudo-pam-guard}}
EOF
sudo chmod 755 /usr/local/sbin/fido2-sudo-pam-guard

Step 2: Install the apt hook.

sudo tee /etc/apt/apt.conf.d/99-fido2-sudo-pam-guard >/dev/null <<'EOF'
{{EMBED:config/99-fido2-sudo-pam-guard}}
EOF

Step 3: Verify the guard works before relying on it.

# Confirm the include is present
sudo grep fido2-local-auth /etc/pam.d/sudo

# Simulate removal, run the guard, confirm it re-adds the line
sudo sed -i '/fido2-local-auth/d' /etc/pam.d/sudo
sudo /usr/local/sbin/fido2-sudo-pam-guard
sudo grep fido2-local-auth /etc/pam.d/sudo

# Confirm sudo still requires FIDO
sudo -k
sudo -v

14. Core FIDO login checkpoint

At this point, the core FIDO login design is complete only if the standalone PAM test, LightDM test, breakglass test, and real sudo -v test all pass.

The remaining sections are desktop-integration and hardening steps: optional su, required greeter-based lock behavior, token-removal greeter switching, password locking, keyring behavior, and rollback.

15. Configure su, optional

This is optional. Preserve pam_rootok.so before the FIDO include so root-originated su keeps normal behavior.

sudo cp -a /etc/pam.d/su /etc/pam.d/su.bak
sudo editor /etc/pam.d/su

The important ordering is:

auth       sufficient pam_rootok.so

@include fido2-local-auth
@include common-auth

su - FIDO_USER
su - BREAKGLASS_USER

16. Configure MATE lock behavior: use the LightDM greeter, not the raw screen locker

The in-process mate-screensaver unlock dialog is not a good primary FIDO unlock surface: like the XFCE screensaver, it authenticates only the currently logged-in user, does not offer Switch User, and can flicker or loop when the token is absent. The design used here sends the user to the LightDM greeter for lock instead, which preserves Switch User and the password-only breakglass account.

Keep the MATE screensaver PAM file sane as a fallback

Even though the primary lock flow uses the LightDM greeter, keep /etc/pam.d/mate-screensaver valid. This prevents confusing PAM errors if MATE still invokes the screensaver dialog during idle timeout or other edge cases.

sudo cp -a /etc/pam.d/mate-screensaver /etc/pam.d/mate-screensaver.bak.before-fido2-local-auth
sudo editor /etc/pam.d/mate-screensaver

Use this content:

#%PAM-1.0

auth include fido2-local-auth
auth include common-auth
auth optional pam_gnome_keyring.so

account required pam_permit.so

The explicit account required pam_permit.so line avoids the pam_unix(...:account): setuid failed account-management problem observed with the analogous XFCE screensaver service.

Test the PAM service directly:

sudo pamtester mate-screensaver FIDO_USER authenticate
sudo pamtester mate-screensaver FIDO_USER acct_mgmt
sudo pamtester mate-screensaver BREAKGLASS_USER authenticate
sudo pamtester mate-screensaver BREAKGLASS_USER acct_mgmt

Make manual lock switch to the LightDM greeter

MATE has no xflock4-style indirection. Its lock shortcut (by default Ctrl+Alt+L) invokes mate-screensaver directly through the mate-settings-daemon media-keys plugin. To route lock to the greeter instead, clear the built-in lock shortcut and add a MATE custom keybinding that runs dm-tool switch-to-greeter. Run these as FIDO_USER inside the graphical MATE session — these are per-user gsettings, not sudo.

# 1. Clear MATE's built-in "lock screen" shortcut (a single-string key) so it
#    no longer launches mate-screensaver directly.
gsettings set org.mate.settings-daemon.plugins.media-keys screensaver ''

# 2. Define one custom shortcut. MATE's media-keys plugin enumerates children
#    of /org/mate/desktop/keybindings/, each using the relocatable schema
#    org.mate.control-center.keybinding with keys name / action / binding.
BASE="org.mate.control-center.keybinding:/org/mate/desktop/keybindings/custom0/"
gsettings set "$BASE" name    "'Lock to LightDM greeter'"
gsettings set "$BASE" action  "'dm-tool switch-to-greeter'"
gsettings set "$BASE" binding "'<Mod4>l'"

Verify the settings were written:

gsettings get org.mate.settings-daemon.plugins.media-keys screensaver
gsettings get "$BASE" action
gsettings get "$BASE" binding

Test manual locking by pressing your chosen shortcut, or by running the command the keybinding invokes directly from the session terminal:

dm-tool switch-to-greeter

Expected behavior:

• The machine switches to the LightDM greeter instead of the mate-screensaver unlock dialog.
• The FIDO user authenticates through LightDM with FIDO PIN + touch.
• The breakglass user remains available with normal password authentication.
• Switch-user behavior remains available at the greeter.

If dm-tool switch-to-greeter fails from a terminal

The greeter switch needs the graphical session environment: DISPLAY, XDG_RUNTIME_DIR, and DBUS_SESSION_BUS_ADDRESS. A nested login shell such as su - FIDO_USER may strip those variables.

echo "$DISPLAY"
echo "$XDG_RUNTIME_DIR"
echo "$DBUS_SESSION_BUS_ADDRESS"

If these are empty, exit the nested login shell and test from the original MATE terminal session. (The token-removal helper in section 17 does not have this limitation — it reconstructs the session environment from loginctl.)

Idle-timeout locking on MATE

MATE cannot run an arbitrary command on idle the way a configurable locker can, so there is no clean way to make idle timeout switch to the greeter. You must choose one of two idle postures, and test the one you pick before considering the setup complete:

1. Disable native idle locking and rely on manual lock (your shortcut → greeter) and token removal (section 17) as the lock triggers. The screen may still blank on idle, but it will not auto-lock — acceptable only where physical access is otherwise controlled. Normal graphical session (as FIDO_USER)

   gsettings set org.mate.screensaver lock-enabled false
   gsettings set org.mate.screensaver idle-activation-enabled false
   gsettings set org.mate.session idle-delay 0

2. Keep native idle locking via mate-screensaver, accepting that an idle lock lands on the in-process FIDO unlock dialog (which you kept PAM-valid above) rather than the greeter. The FIDO PIN + touch flow still works, but Switch User and breakglass are not available from that dialog until the token is reinserted.

Check which lockers are running:

pgrep -a 'mate-screensaver|light-locker|xscreensaver|xsecurelock'

17. Switch to the LightDM greeter when the FIDO key is removed

This section sends the machine to the LightDM greeter when the FIDO token is removed. It depends on the greeter-based lock behavior configured and tested in the previous section. This is part of the intended desktop behavior for this FIDO-only setup, but it is still not an authentication control; the real authentication control remains the FIDO/PAM login policy.

17.1. Confirm the greeter switch command exists

command -v dm-tool

Expected result:

/usr/bin/dm-tool

From the real MATE terminal session, test switching to the greeter:

dm-tool switch-to-greeter

Expected behavior: the session switches to the LightDM greeter. From there, the FIDO user should be able to authenticate with FIDO PIN + touch, and the breakglass user should be able to authenticate with a normal password.

17.2. Find the token's udev identifiers

Insert the FIDO key, then monitor udev events:

sudo udevadm monitor --udev --environment

Remove the FIDO key and look for the hidraw remove event. Prefer the event that includes ID_FIDO_TOKEN=1 and ID_SECURITY_TOKEN=1.

ACTION=remove
SUBSYSTEM=hidraw
DEVNAME=/dev/hidraw1
ID_FIDO_TOKEN=1
ID_SECURITY_TOKEN=1
ID_VENDOR_ID=096e
ID_MODEL_ID=0858
ID_MODEL=FIDO

Record ID_VENDOR_ID and ID_MODEL_ID. If your token exposes a truly unique serial number, you may also match on that, but some tokens expose a generic product serial string rather than a per-token serial.

17.3. Create the greeter-switch helper

This helper is run by root through udev/systemd, finds the active local graphical session, reconstructs the session environment, and runs dm-tool switch-to-greeter as the graphical user.

sudo tee /usr/local/sbin/fido-remove-switch-to-greeter >/dev/null <<'EOF'
{{EMBED:scripts/fido-remove-switch-to-greeter}}
EOF

sudo chown root:root /usr/local/sbin/fido-remove-switch-to-greeter
sudo chmod 0755 /usr/local/sbin/fido-remove-switch-to-greeter

17.4. Test the helper manually

sudo /usr/local/sbin/fido-remove-switch-to-greeter

Expected behavior: the session switches to the LightDM greeter. After returning, inspect logs:

sudo journalctl -b --since "3 minutes ago" | grep -Ei 'fido-switch-greeter|dm-tool|lightdm|greeter'

If dm-tool reports Not running inside a display manager, XDG_SEAT_PATH not defined, verify that the helper includes the XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 environment variable.

17.5. Test a logging-only udev rule first

Before letting udev switch the greeter, confirm the rule fires on the correct remove event. Replace the vendor/model IDs with the values observed from your token.

sudo tee /etc/udev/rules.d/85-fido-lock-on-remove-test.rules >/dev/null <<'EOF'
{{EMBED:config/85-fido-lock-on-remove-test.rules}}
EOF

sudo udevadm control --reload-rules

Remove the token, then check for the test log:

sudo journalctl -b --since "2 minutes ago" | grep -i fido-udev-test

If the test log appears, remove the test rule:

sudo rm -f /etc/udev/rules.d/85-fido-lock-on-remove-test.rules
sudo udevadm control --reload-rules

17.6. Create the real udev removal rule

Do not run dm-tool directly from udev. udev jobs should be short-lived. Use systemd-run --no-block to hand the work off to systemd.

sudo tee /etc/udev/rules.d/85-fido-lock-on-remove.rules >/dev/null <<'EOF'
{{EMBED:config/85-fido-lock-on-remove.rules}}
EOF

sudo udevadm control --reload-rules

17.7. Test token removal

1. Stay logged into MATE.
2. Insert the FIDO key.
3. Remove the FIDO key.
4. The machine should switch to the LightDM greeter.
5. Select the FIDO user and reinsert the token to authenticate with FIDO PIN + touch, or select the password-only breakglass user.

Check logs after the test:

sudo journalctl -b --since "3 minutes ago" | grep -Ei 'fido-switch-greeter|fido-udev|udev|dm-tool|lightdm|greeter'

17.8. Notes on testing the greeter switch by hand

Running dm-tool switch-to-greeter by hand only works from the original graphical MATE session environment. It needs DISPLAY, XDG_RUNTIME_DIR, and DBUS_SESSION_BUS_ADDRESS. If those variables are empty, such as inside a nested su - login shell, the manual command may fail even though the desktop session is healthy.

echo "$DISPLAY"
echo "$XDG_RUNTIME_DIR"
echo "$DBUS_SESSION_BUS_ADDRESS"

The greeter-switch helper does not depend on the current shell environment; it reconstructs the graphical session environment from loginctl.

17.9. Rollback the removal-switch feature (optional)

sudo rm -f /etc/udev/rules.d/85-fido-lock-on-remove.rules
sudo rm -f /etc/udev/rules.d/85-fido-lock-on-remove-test.rules
sudo rm -f /usr/local/sbin/fido-remove-switch-to-greeter
sudo udevadm control --reload-rules

18. Extended test matrix before reboot

Reboot only after tests pass

sudo reboot

19. Disable Unix password login for FIDO users

After the FIDO login path, LightDM greeter lock behavior, sudo behavior, breakglass account, and recovery path have been fully tested, the FIDO-enabled user can be made token-only by locking that user's Unix password. This prevents password-based authentication for that user while keeping the account itself valid for normal login, group membership, sudo policy, and PAM account/session checks.

Lock the password, not the account. Use passwd -l for the FIDO user. Do not expire the account, disable the shell, delete the user, or remove normal group memberships.

sudo passwd -l FIDO_USER

Verify the password state:

sudo passwd -S FIDO_USER
sudo getent shadow FIDO_USER

The shadow password field should begin with !, indicating that password authentication is locked for that account. The account should still exist and should still be a member of fido-login.

Verify group membership:

id FIDO_USER
getent group fido-login

Retest after locking the password

Run the core tests again before logging out or rebooting. Prefer operational tests from the actual FIDO_USER graphical session over synthetic-only tests.

sudo -k
sudo -v
# then press Super+L (or run: dm-tool switch-to-greeter)

sudo pamtester lightdm FIDO_USER authenticate
sudo pamtester lightdm BREAKGLASS_USER authenticate
sudo pamtester mate-screensaver FIDO_USER authenticate

Confirm the Unix password itself is locked

If su has been modified to include fido2-local-auth, then su - FIDO_USER may still succeed through FIDO. That is expected. To prove that the Unix password itself is locked, test a password-only path such as an unmodified TTY login for FIDO_USER, or perform this check before enabling FIDO for su.

FIDO-protected PAM services should continue to work because fido2-local-auth exits successfully before falling through to common-auth.

Restore password login later, if needed

sudo passwd -u FIDO_USER

Only unlock the password if you intentionally want password-based authentication restored for that account.

20. Optional: GNOME Keyring and Chrome/Chromium prompts

After converting a user to FIDO-only login, Chrome or Chromium may ask for the GNOME Keyring password when it tries to access stored browser secrets. This is expected.

This means FIDO2 can authenticate the desktop login, but it does not automatically decrypt an existing password-protected keyring. The keyring password remains separate.

20.1. Options

20.2. Install Seahorse

The graphical keyring editor may not already be installed. Install Seahorse:

sudo apt install seahorse

Launch it:

seahorse

20.3. Set the login keyring password blank

1. Open Passwords and Keys / Seahorse.
2. Find the Login keyring.
3. Right-click the Login keyring and choose Change Password.
4. Enter the current keyring password.
5. Leave the new password fields blank.
6. Accept the warning about storing passwords unencrypted, if this matches your threat model.

After this, Chrome/Chromium should stop asking for the keyring password when launched inside the FIDO-only user session.

20.4. Do not automate this step

This walkthrough treats blanking the keyring password as an explicit user choice. Do not automate it in the PAM migration script, because it changes how local application secrets are protected.

21. Emergency rollback

If a PAM change breaks authentication and you still have a root-capable shell, remove the shared include references first:

sudo sed -i '/fido2-local-auth/d' /etc/pam.d/lightdm /etc/pam.d/sudo /etc/pam.d/su /etc/pam.d/mate-screensaver 2>/dev/null || true
sudo rm -f /etc/pam.d/fido2-local-auth
sudo rm -f /etc/lightdm/lightdm.conf.d/50-manual-login.conf
sudo rm -f /etc/udev/rules.d/85-fido-lock-on-remove.rules
sudo rm -f /etc/udev/rules.d/85-fido-lock-on-remove-test.rules
sudo rm -f /usr/local/sbin/fido-remove-switch-to-greeter
sudo rm -f /usr/local/sbin/lock-on-fido-remove
sudo udevadm control --reload-rules

If you need to restore backed-up PAM files:

sudo test -e /etc/pam.d/lightdm.bak && sudo cp -a /etc/pam.d/lightdm.bak /etc/pam.d/lightdm || true
sudo test -e /etc/pam.d/sudo.bak && sudo cp -a /etc/pam.d/sudo.bak /etc/pam.d/sudo || true
sudo test -e /etc/pam.d/su.bak && sudo cp -a /etc/pam.d/su.bak /etc/pam.d/su || true
sudo test -e /etc/pam.d/mate-screensaver.bak.before-fido2-local-auth && sudo cp -a /etc/pam.d/mate-screensaver.bak.before-fido2-local-auth /etc/pam.d/mate-screensaver || true
sudo test -e /etc/pam.d/mate-screensaver.bak && sudo cp -a /etc/pam.d/mate-screensaver.bak /etc/pam.d/mate-screensaver || true

Restart display manager only when ready

sudo systemctl restart lightdm

If you are locked out entirely, boot recovery or a live USB, mount the system, and remove the fido2-local-auth includes from the PAM files.

22. Option notes and policy choices

Common pam_u2f options used here

pamu2fcfg options used here

Why edit selected PAM services?

This guide edits LightDM, sudo, optional su, and the actual screen-locker PAM file. It does not edit common-auth globally, because a mistake there can break too many authentication paths at once.

Lock policy used here

This guide uses the LightDM greeter as the normal lock/unlock surface for FIDO users. The raw mate-screensaver unlock dialog is kept PAM-valid as an idle-timeout fallback, but it is not the preferred primary unlock UI for FIDO-only use.

23. References and source notes

• Packages (Debian/Ubuntu/Mint): libpam-u2f, pamu2fcfg, fido2-tools, and pamtester.
• MATE settings schemas: org.mate.settings-daemon.plugins.media-keys, org.mate.control-center.keybinding, org.mate.screensaver, and org.mate.session (via gsettings).
• Yubico pam_u2f manual: documents authfile, cue, pinverification, userverification, nouserok, and passwordless examples.
• Yubico pamu2fcfg manual: documents -N and -n.
• libfido2 fido2-token and fido2-cred manuals: document listing tokens, setting/changing PINs, and make-credential tests with -t pin=true.
• pam_succeed_if manual: documents group-based selection with user ingroup.
• LightDM common configuration and sample config: document greeter-hide-users and greeter-show-manual-login.
• loginctl manual: documents lock-sessions.
• dm-tool manual: documents switch-to-greeter and the LightDM seat environment it requires.
• udev documentation: covers matching USB device add/remove events with udev rules; systemd's fido_id builtin sets ID_FIDO_TOKEN.