So I wrote this a few years ago for Ubuntu and it’s pretty useful, so I ported it over from my old blog. I have performed this configuration for Arch Linux as well and frankly I should write a blog about it, because it was a little fiddly.

Anyway here’s the old blog.

So one thing I really appreciate about Yubikeys is that they force the issue of security.  They are a discrete, physical second factor. Don’t have your Yubikey? Good luck getting on to the system. This isn’t to say that somehow the Yubikey (Or similar, U2F-capable devices) will secure everything under the sun, and let’s be real there are always going to be side channel attacks, but the point of any endeavor in security is to delay a sufficiently motivated attacker until they A.) Get caught, or B.) Lose motivation. Traditionally, setting up second factor authentication on end-user boxes has been a bit of a pain, requiring an agent (Such as the old Windows Yubico agent that relied on a HMAC challenge-response setup) some other sort of implementation. Because of the nature of PAM this ties right in, and because it’s using FIDO2 it should be good to use for the foreseeable future.

Installing the plugin

I’m not going to belabor the process of installation of the U2F PAM component- Yubico does a great job outlining the basics here and outlining the details of of what pam_u2f can do here . While the instructions are geared towards Ubuntu, one could realistically use them for anything that relies on apt; heck, if one were so inclined they could roll their own off of the Yubico github, but that’s neither here nor there.

What I do want to do instead is discuss how I have it configured, why I configured it the way I did, and options.

A Word of Caution

So I need to be real with you here- modifying PAM is scary. Modifying PAM without knowing what you are doing can and will get you locked out of a system if you do it all in one shot. Always leave a terminal open that is ready to reverse changes if you mess up a change to, say, sudo or su. There is no faster way to need to run a live instance and rip apart a LUKS-encrypted partition to roll back PAM changes than to YOLO it here.

Be safe.

Pam.d Configuration

If you look at the Yubico developer documents, it’s a pretty straight-forward exercise. You will modify the relevant pam.d files to do what you want them to do- if for instance you want every PAM-related event to require the yubikey, you would modify your common auth file. If you want a more nuanced/sane approach, consider the following files to modify:

“Point of Entry” Scenarios – Places where someone might boot the PC, wake it, etc.
/etc/pam.d/gdm-password
/etc/pam.d/login
<If you rely on a screensaver and it ties into PAM, this would be a good place to lock up too>

“Ooops I left my computer unlocked” Scenarios
/etc/pam.d/sudo
/etc/pam.d/su

Where you are looking to modify is right after the “@include common-auth” line in these respective files.

An example for how to set this beast up in PAM might be the following-

auth required pam_u2f.so prompt nodetect cue nouserok authfile=/etc/yubico/u2f_keys

What this does for us, the consumer, is the following:

  • Prompt for a Yubikey if one isn’t inserted.
  • Prompt for us to press the button.
  • Mitigates revealing information about the authentication stack if a token is inserted but not properly configured.
  • Allows users who are not currently configured to use u2f (Other accounts not yet configured?) to log in.

Assuming you’re slightly more paranoid and want as little as possible revealed about what is going on or why you have a weird looking USB thumb drive in your PC, you can use the following configuration:

auth required pam_u2f.so authfile=/etc/yubico/u2f_keys

In this case the Yubikey will simply blink (Like it did during initial configuration), you press the button, and if it is set up to the user it succeeds and lets you in.

Go foward, and be safe.