Using U2F keys in Debian
U2F is an open standard for hardware two-factor / multi-factor authentication (2FA). U2F tokens are available in a variety of form factors, including various versions of USB, Bluetooth, and NFC. Any U2F token should work under Debian, with no drivers or low level configuration required.
Many hardware tokens offer a variety of security protocols in addition to U2F (e.g., OATH-TOTP, OATH-HOTP, PIV, OpenPGP, OTP); these are often more expensive than U2F-only tokens. This article focuses exclusively on U2F (and FIDO); for some more general information, see here.
PAM Setup
PAM integration is accomplished via Yubico's pam-u2f module.
Check for the USB dongle:
lsusb | grep U2F
Install the required libraries:
sudo apt-get install pamu2fcfg libpam-u2f
Create authorization maps (full documentation):
mkdir -p ~/.config/Yubico pamu2fcfg >> ~/.config/Yubico/u2f_keys
PAM configuration
WARNING: it is possible to lock yourself out of your system while changing PAM configuration.
PAM can be configured via either /etc/pam.conf or (more commonly) individual appropriately named files under /etc/pam.d/. Using the latter method, add lines like the following to files such as /etc/pam.d/xscreensaver and /etc/pam.d/lightdm
To allow password-less login using just the U2F key, use lines like:
auth sufficient pam_u2f.so
To use the U2F key as a required second factor (2FA), use lines like:
auth required pam_u2f.so
Note that integration with the existing default PAM configuration files supplied by Debian is tricky, and the order of the lines in the PAM files is apparently important. When using sufficient, it seems that the line should be added before @include common-auth, to avoid being asked first for a password, whereas when using required, the line may be added afterward. See the documentation for more information, including some useful module options such as cue and debug
Note also that PAM configuration changes do not take effect for already authenticated users; to test, either log out and log back in, or attempt to authenticate as a different user.
Additional resources:
SSH
OpenSSH supports FIDO/U2F keys from version 8.2:
ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk
As per the documentation:
- This will yield a public and private key-pair. The private key file should be useless to an attacker who does not have access to the physical token. After generation, this key may be used like any other supported key in OpenSSH and may be listed in authorized_keys, added to ssh-agent(1), etc. The only additional stipulation is that the FIDO token that the key belongs to must be attached when the key is used.
See the documentation and man ssh-keygen for more details.
Website 2FA
Many websites can use U2F tokens for 2FA; see here for a list. No client-side configuration is required; simply follow the site's directions to register the key with the site, and subsequently follow the site's directions to authenticate with the key.
Disk (LUKS2) Unlocking
U2F has been superseded by FIDO2. It is possible to use a FIDO2 security key that supports the HMAC Secret Extension (hmac-secret) (which is apparently most of them) to unlock a LUKS2 volume. There are a variety of ways to do this, but the easiest and most modern (assuming the use of systemd) is probably via the systemd-cryptenroll tool. The basic procedure is documented here, but properly setting up unlocking on boot is not covered there, and currently does not work on Debian without the use of somewhat hackish solutions; for details see here and here.
For other methods to use various types of security keys for disk unlocking (that may or may not be easy to set up on Debian), see here, here, and here.