The Ultimate YubiKey Guide and Setup for Linux

I wrote a series of articles about YubiKey over the past few years. The original idea was simple: move from "2FA because I have to" to "2FA/MFA by architecture." Along the way, the key stopped being an expensive trinket and became a useful component of a coherent setup: hardened Linux, SSH less dependent on sensitive files, GPG less exposed, and authentication more resistant to phishing.

This post is a unified summary of the original series, with direct references, and with technical updates that make sense in 2026 — especially around FIDO2/WebAuthn, passkeys, and PIN/management policies that have evolved significantly. I also connect it with my other posts on cryptography, because YubiKey is a practical consequence: you stop talking about "crypto" as an abstract concept and start operationalizing keys, signatures, identity, and risk.

Before anything: YubiKey is not "improved 2FA"

The temptation is to treat YubiKey as "the same 2FA, just on USB." That reduces the subject to the worst use case: typeable OTP, user-dependent, exposed to phishing and clunky UX. The real value appears when you understand it supports multiple protocols, and each one changes the type of attack you need to defeat.

When you move from codes to FIDO2/WebAuthn, for example, you're not "improving 2FA" — you're changing the category: authentication becomes bound to the origin (the site), which drastically reduces the class of attacks based on fake pages and reusable secret harvesting. When you bring the key to SSH, you reduce the impact of $HOME theft/exfiltration. When you bring it to OpenPGP, you decrease key material exposure and improve your discipline around subkeys and purposes.

2FA/MFA — The Basics

Two-factor authentication is an additional security layer that requires at least two of the following:

What you know — passwords, PINs
What you have — a physical device, a card
Who you are — biometrics

An ATM withdrawal covers two: you know your PIN and have your debit card. A bank vault can use all three, with passwords, access cards, and fingerprint scans required to open it.

Traditional email and password logins cover only the first — what you know. You know your email address and password, and generally, they're easy enough for someone else to guess or crack. That's what makes them so insecure. Two-factor authentication adds a second layer to digital logins.

Almost every service now allows users to enable two-factor authentication. We're at a turning point where having 2FA enabled is mandatory in more and more services and apps.

Passwords are terrible. Most are too easy for hackers to guess, and the rest are too long or complicated for humans to remember. Even secure passwords are useless after a leak, and leaks are basically inevitable. For these reasons and more, it's a good idea not to rely exclusively on passwords.

2FA Methods

SMS or email codes — Apps send a code you need to enter before logging in. Easiest to set up because you don't need to install software or buy hardware. Also the least secure because email and SMS are not encrypted and are easily compromised.

Authenticator apps — The apps you want to log into request a code you can retrieve by opening an app on your phone, like Google Authenticator or Authy. Much more secure than relying on SMS or email, but not exactly convenient — you need to grab your phone, open an app, and type a code.

Hardware authentication — Apps ask you to plug in a device like a YubiKey and press a button. The YubiKey sends a unique code that the service uses to confirm your identity. More secure because the codes are much longer and more convenient (SMS/token codes are typically 4-6 numeric digits), and you don't need to type them yourself.

What is a YubiKey?

The YubiKey is a device that makes two-factor authentication as simple as possible. Instead of a code being sent to you (SMS) or generated by an app on your phone (Authy, Authenticator, bank tokens...), you just press a button on your YubiKey.

Each device has a unique built-in code used to generate codes that help confirm your identity. YubiKey is not the only hardware 2FA device on the market — just the most popular.

Why is it better?

Convenience — SMS, email, and authenticator apps require you to copy-paste or manually enter a code. With YubiKey, just press a button on a device connected to your computer.
Much longer codes — Other 2FA methods typically send only a six-digit code. YubiKeys don't ask you to type a code manually, so they can use much longer codes. More secure.
Easy to migrate — New computer? Unplug your YubiKey from the old one, plug it into the new one, and log into all your apps as before. You can also use one key to log into your account on multiple computers.
Extremely hard to hack — It's relatively easy for hackers to compromise your email or SMS. It's much harder — nearly impossible with current technology — to forge the codes generated by a unique hardware device.

How it works: yubico.com/why-yubico/how-the-yubikey-works

Catalog of supported services/sites/apps: yubico.com/works-with-yubikey/catalog

YubiKey 5 NFC — Overview

Released in 2018. Primary functions:

FIDO2 — Secure single and multi-factor authentication, stores up to 25 credentials protected by a PIN. Enables passwordless login where the YubiKey, unlocked by PIN and authorized by touch, can log into accounts without entering a username or password. FIDO certified.
OTP — Two programmable slots, each can hold: Yubico OTP, HMAC-SHA1 Challenge-Response, Static Password, or OATH-HOTP.
U2F — Unlimited U2F credentials. FIDO certified.
OATH — Up to 32 OATH credentials, supports OATH-TOTP (time-based) and OATH-HOTP (counter-based). Requires Yubico Authenticator.
PIV (Smart Card) — PIV-compatible smart card. Supported algorithms: RSA 1024/2048, ECC P256/P384. Slots: 9a (Authentication), 9b (Management Key), 9c (Digital Signature), 9d (Key Management), 9e (Card Authentication), f9 (Attestation), 82-95 (Retired Key Management).
OpenPGP — Implements OpenPGP Smart Card spec v2.0 (v3.4 on firmware 5.2.3+). Supported algorithms: RSA 1024-4096, secp256r1, secp256k1, secp384r1, secp521r1, brainpoolP256r1/384r1/512r1, curve25519, x25519 (decrypt only), ed25519 (sign/auth only). GnuPG 2.0+ required for keys above 2048 bits.
Differentiator: NFC

For SRE/DevOps context, the most relevant protocols are: PIV, OpenPGP, HMAC-CR, and FIDO2. The private key never leaves the chip — the app sends data to the YubiKey for processing; it returns the result. That's what differentiates an HSM from a .pem file on disk.

Linux Installation

The YubiKey works out of the box — no drivers needed. Plug it into a USB port (gold contacts facing up on most computers), and the LED should light up solid green. It uses standard USB keyboard drivers.

On Linux, the key is recognized as a QWERTY keyboard input to enter the generated code when you touch the gold surface (the area with the "Y" logo).

You can use it with any software token generator (Google Authenticator, Authy, LastPass Authenticator, etc.), but for full functionality (OATH via Authenticator, PIV, OpenPGP), you'll need the smartcard stack.

Installing pcscd

The pcscd daemon is middleware for accessing smart cards — it allocates/deallocates reader drivers dynamically at runtime and manages connections.

# Debian/Ubuntu
sudo apt-get install pcscd

# Arch
sudo pacman -S yubikey-manager ykpers libfido2 pcsc-tools opensc

# Fedora
sudo dnf install yubikey-manager ykpers libfido2 pcsc-lite opensc

If installing via Snap or adding Yubico repositories on Ubuntu, pcscd is not required separately.

Verify the key is present:

ykman info

Yubico Apps

Yubico Authenticator — Complements the YubiKey for sites/apps that don't support hardware as an authenticator. You scan the QR code (or register manually) and it generates the numeric token requested after successful password login. Available for desktop and mobile (Android/iOS). It requires the YubiKey and PIN to open and display tokens.

sudo snap install yubioath-desktop

Downloads: Yubico Authenticator | Snap

YubiKey Manager — Optional. For configuring tokens and managing slots. Available as AppImage and CLI.

# Ubuntu
sudo add-apt-repository ppa:yubico/stable && sudo apt-get update

# CLI
sudo apt install yubikey-manager

# Personalization Tool
sudo apt install yubikey-personalization-gui

# PAM modules
sudo apt install libpam-yubico libpam-u2f

Downloads: YubiKey Manager | Releases

Configuring Your YubiKey

Each site/service/app has its own path to enable the key, usually in security settings near the password change option. Services that don't support the physical key support 2FA via app.

Yubico maintains a knowledge base with step-by-step instructions for configuring your key on various services:

Plug in your YubiKey
Go to yubico.com/setup and click your device
Browse the list of compatible apps
Follow the instructions

Yubico API

To get your API ID and Secret, enter an email and touch the key at: upgrade.yubico.com/getapikey

Despite the name "upgrade", the API is free.

Client ID:  58107
Secret key: 8xpmpAy2OtmZAAeXP/0NUed/aLB=

PAM Configuration — libpam-yubico

There are two ways to configure PAM authentication: libpam-yubico and libpam-u2f. You can configure both on the same host, but each file in pam.d should use only one method (no point in requiring two tokens for the same login).

Create the authentication file at /etc/yubikeys_mappings:

#username:first12charsofkey
esl1h:ccccedrrdvhv

If a user has more than one key, separate the first 12 characters of each with a semicolon. One line per user.

Optionally, keep an individual file in each user's home: ~/.yubico/authorized_yubikeys. If the key file is omitted in pam.d config, it will look in the user's home.

Add the ID and Secret:

sudo dpkg-reconfigure libpam-yubico

On the next screen (PAM enable profile), keep the defaults.

PAM Configuration — libpam-u2f

sudo apt install libpam-u2f pamu2fcfg

# Create config directory
mkdir -p ~/.config/Yubico

# Generate authentication config
pamu2fcfg > ~/.config/Yubico/u2f_keys

If you registered a PIN on the key, it will be requested. Then touch the key and it will populate the file.

Common PAM Setup

For both configurations above, in /etc/pam.d/common-auth, add try_first_pass as a parameter to pam_unix.so:

auth [success=1 default=ignore]  pam_unix.so nullok_secure try_first_pass

Add at the beginning of /etc/pam.d/login:

# Using libpam-yubico (shows prompt for key):
auth sufficient pam_yubico.so id=58107
# Replace with YOUR ID!

# OR using libpam-u2f (no visual prompt, key LED blinks):
auth required pam_u2f.so

The difference: libpam-yubico presents a prompt asking for the key; with pam_u2f, nothing visual is shown — only the key's LED blinks, indicating you should touch it.

This does not modify the graphical interface login, only the console terminal login.

2FA for sudo

With libpam-u2f configured, edit /etc/pam.d/sudo. Right below the @include common-auth line, add:

auth required pam_u2f.so

When running sudo: enter password + [Enter], then touch the key to insert the token.

SSH with PAM

With pam_u2f configured, add to /etc/pam.d/sshd below @include common-account:

auth       required   pam_u2f.so

Important caveat: this only works on localhost. For remote hosts, additional configuration and sshd_config parameters are needed for a proper SSH + 2FA environment. Alternatives: use YubiKey with FIDO U2F to generate the SSH key, or use only the YubiKey token for SSH login (without password, key, or 2FA) through PGP or PIV.

OpenSSH with YubiKey + ed25519

Since OpenSSH 8.2 (released 2020), U2F/FIDO devices are supported using the ecdsa-sk and ed25519-sk public key types (FIDO2, YubiKeys with firmware above 5.2.3) and their certificates. The sk stands for "Security Key."

Check your YubiKey firmware version:

lsusb -v 2>/dev/null | grep -A2 Yubico | grep "bcdDevice" | awk '{print $2}'

Above 5.2.3 = FIDO2 support.

The advantage: you get a normal public/private key pair, but the private key file doesn't contain the actual sensitive private key — instead, it contains a "key handle" used by the YubiKey to derive the real private key at signing time.

ssh user@host -i .ssh/id_ed25519_sk [+ passphrase] [+ yubikey-token]

Even if the key leaks, it's not enough to access the host (even knowing the username).

Why ed25519 over ECDSA: ECDSA has known vulnerabilities. RSA 4096-bit has comparable complexity to Ed25519, but Ed25519 is still preferred due to concerns that RSA may be vulnerable to the same strength concerns as DSA.

Generate keys:

# ECDSA-SK
ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk

# Ed25519-SK (preferred)
ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519_sk

# FIDO2 resident key (stored on YubiKey, portable)
ssh-keygen -t ed25519-sk -O resident -O verify-required \
    -C "esli@infra-prod" -f ~/.ssh/id_ed25519_yk

# Export handles from resident keys (use on another host without the file)
ssh-keygen -K

# Add to ssh-agent with mandatory touch confirmation
ssh-add -K ~/.ssh/id_ed25519_yk

After generating keys, add the public key (.pub) to authorized_keys on the server and/or add via ssh-agent (ssh-agent, ssh-add).

Force the SSH server to accept only YubiKey-generated keys:

In /etc/ssh/sshd_config:

PubkeyAcceptedKeyTypes sk-ecdsa-sha2-nistp256@openssh.com,sk-ssh-ed25519@openssh.com
# Or ed25519 only:
# PubkeyAcceptedKeyTypes sk-ssh-ed25519@openssh.com

GPG Keys

Creating RSA Keys

gpg --gen-key
# Or with full options:
gpg --expert --full-generate-key

Choose: (1) RSA and RSA, 4096 keysize, 3072 for subkeys, expiration as desired, then fill in identification data and set a password.

pub   rsa4096 2023-02-02 [SC]
      F40975F47855887B2084E7D18A74F970158F02B8
uid                      Esli Silva (https://esli.blog.br) <not.announced@simplelogin.fr>
sub   rsa3072 2023-02-02 [E]

Encrypting/Decrypting with GPG

# Encrypt (no password prompt — uses public key)
gpg -r F40975F47855887B2084E7D18A74F970158F02B8 -e -a -o Encrypted.pdf Original.pdf

# Decrypt (requires key + password; import key first on other hosts)
gpg -r F40975F47855887B2084E7D18A74F970158F02B8 -d -o Decrypted.pdf Encrypted.pdf

Adding Subkeys

gpg --expert --edit-key F40975F47855887B2084E7D18A74F970158F02B8

At the gpg> prompt:

gpg> addkey
# Select option (8) RSA (set your own capabilities)
# Toggle S/E/A to set desired capabilities
# S = Sign, E = Encrypt, A = Authenticate

The same key should NEVER be used for different purposes. The subkey format exists precisely to separate signing, encryption, and authentication — this improves security and your ability to operate with discipline (revoke, rotate, isolate).

RSA keypairs in PGP can still have all capability bits at once, but all other key types explicitly use different algorithms for signing and encryption — an ECDSA or EdDSA key can only sign/verify, and an ECDH key can only encrypt/decrypt. Since the master key in PGP is used to certify other people's keys and your own subkeys, it must be a signing-capable algorithm (certify).

After setting capabilities and confirming, save:

gpg> quit
Save changes? (y/N) y

Backup/Export GPG Keys

# Export secret key to stdout
gpg --export-secret-key --armor F40975F47855887B2084E7D18A74F970158F02B8

# Export public key to file
gpg --output public.pgp --armor --export F40975F47855887B2084E7D18A74F970158F02B8

# Export private key to file
gpg --output private.pgp --armor --export-secret-key F40975F47855887B2084E7D18A74F970158F02B8

Creating ECC Keys

Same steps, selecting ECC at the start:

gpg --expert --full-generate-key
# Select (11) ECC (set your own capabilities)
# Toggle capabilities as needed (S, A, Q to finish)
# Select (1) Curve 25519
# Set expiration, fill identification data

pub   ed25519 2023-02-02 [SCA]
      C512D2E3863F0D4902D63EC5BAB622429963AB29
uid                      Esli Silva (https://esli.blog.br) <my.develoment@aleeas.com>

When editing an ECC key and calling addkey, the option (8) with multiple capabilities is no longer available — ECC enforces algorithm separation by design.

Listing GPG Keys

gpg --list-keys

Importing Keys to YubiKey

gpg --edit-key F40975F47855887B2084E7D18A74F970158F02B8

gpg> keytocard
Really move the primary key? (y/N) y
Please select where to store the key:
   (1) Signature key
   (3) Authentication key
Your selection? 3

GPG with YubiKey for File/Secrets Encryption

# Check if YubiKey is recognized as GPG card
gpg --card-status

# Encrypt file to your own key (on YubiKey)
gpg --encrypt --recipient esli@esli.blog.br secrets.txt

# Decrypt — YubiKey performs the operation, requires PIN
gpg --decrypt secrets.txt.gpg > secrets.txt

# Practical: secrets in a Git repo
echo "DB_PASSWORD=hunter2" | gpg --encrypt -r esli@esli.blog.br --armor > .secrets.gpg
# At deploy time:
gpg --decrypt .secrets.gpg | source /dev/stdin

HMAC-SHA1 Challenge-Response for Key Derivation

Slot 2 of the YubiKey can be configured for HMAC-CR. You send a challenge (up to 64 bytes), it returns a 20-byte HMAC. This becomes the basis for an encryption key.

Encrypt:

#!/usr/bin/env bash
# yk-encrypt.sh — Encrypt file using YubiKey as key factor
set -euo pipefail

FILE="\({1:?Usage: \)0 <file>}"
SLOT=2

# Generate random challenge and save alongside encrypted file
CHALLENGE=$(openssl rand -hex 32)
echo "[*] Sending challenge to YubiKey (slot $SLOT)..."

# ykchalresp returns HMAC in hex
HMAC=\((ykchalresp -2 "\)CHALLENGE" 2>/dev/null) || {
    echo "[!] YubiKey did not respond. Inserted and configured?" >&2
    exit 1
}

# Derive AES-256 key via PBKDF2 (challenge + HMAC as material)
KEY=\((echo -n "\){CHALLENGE}${HMAC}" | openssl dgst -sha256 -binary | xxd -p -c 256)

# Encrypt with AES-256-CBC
openssl enc -aes-256-cbc -pbkdf2 -iter 600000 \
    -k "$KEY" \
    -in "$FILE" \
    -out "${FILE}.yk.enc"

# Save the challenge (without the HMAC — without the physical key, can't open)
echo "\(CHALLENGE" > "\){FILE}.yk.challenge"

echo "[+] Encrypted file: ${FILE}.yk.enc"
echo "[+] Challenge saved: ${FILE}.yk.challenge"
echo "[!] Without the YubiKey, the file cannot be decrypted."

Decrypt:

#!/usr/bin/env bash
# yk-decrypt.sh
set -euo pipefail

ENC_FILE="\({1:?Usage: \)0 <file.yk.enc>}"
CHALLENGE_FILE="${ENC_FILE%.enc}.challenge"
SLOT=2

CHALLENGE=\((cat "\)CHALLENGE_FILE")
echo "[*] Waiting for YubiKey..."
HMAC=\((ykchalresp -2 "\)CHALLENGE" 2>/dev/null) || { echo "[!] YubiKey failed" >&2; exit 1; }

KEY=\((echo -n "\){CHALLENGE}${HMAC}" | openssl dgst -sha256 -binary | xxd -p -c 256)

openssl enc -d -aes-256-cbc -pbkdf2 -iter 600000 \
    -k "$KEY" \
    -in "$ENC_FILE" \
    -out "${ENC_FILE%.yk.enc}.decrypted"

echo "[+] Decrypted: ${ENC_FILE%.yk.enc}.decrypted"

Protocol Quick Reference

Need	Protocol	Tool/Lib
File encryption	PIV (RSA/ECDH) or OpenPGP	`age-plugin-yubikey`, `gpg`, `piv-go`, `yubikey` (Rust)
SSH without password	FIDO2 (`ed25519-sk`)	`ssh-keygen -t ed25519-sk`
2FA on web apps	FIDO2/WebAuthn	`fido2` (Python), `webauthn` (Go/Rust)
Key derivation (disk, vault)	HMAC-SHA1 CR	`ykchalresp`, `libykpers`, `yubikey-manager`
Code/commit signing	OpenPGP	`gpg --card-status`
Legacy system auth	OTP (HOTP/TOTP)	`ykman oath`
Privileged access with PIN	PIV	`piv-go`, `yubikey` (Rust), `opensc`

What Protocols Are Available?

Protocol	Interface	Typical Use
OTP (Yubico OTP / HOTP / TOTP)	HID (keyboard)	Classic 2FA
FIDO2 / WebAuthn	HID	Passwordless login
U2F	HID	2FA on web apps
PIV (Smart Card)	CCID	Encryption, SSH, certificates
OpenPGP	CCID	GPG, file encryption
HMAC-SHA1 Challenge-Response	HID	Key derivation, disk encryption
OATH (TOTP/HOTP)	CCID	OTP generation via app

Real-World YubiKey Applications for SRE/DevOps

In the real world, YubiKey stops being "just another authentication factor" and becomes a physical control point over critical actions. In infrastructure environments, this completely changes the threat model: compromising credentials isn't enough — the attacker also needs the physical device.

Privileged SSH access — Instead of relying on private keys stored on the filesystem (even with correct permissions), authentication requires physical presence and operator interaction. This eliminates an entire class of attacks based on key exfiltration (malware, compromised backups, home directory leaks). In environments with bastion hosts or access to sensitive Kubernetes clusters, this drastically reduces the risk of silent lateral movement.

Secrets protection in pipelines — Instead of storing credentials in plaintext or in misconfigured vaults, the YubiKey can serve as a root of trust for decrypting data only at execution time. Particularly useful in semi-manual pipelines (controlled deploys, runbooks, emergency operations) where human presence is already expected. In practice, the secret only "exists" in memory for a few seconds and depends on a physical factor to be accessed.

Non-repudiation for compliance — Each device has a unique identifier, making it possible to tie critical actions — key rotation, production config changes, sensitive data access — to a specific hardware device. This enables stronger auditing: not just "which user did it" but "which physical device was used."

Code signing and supply chain — GPG or hardware-based signing ensures commits, tags, and artifacts can only be signed with physical presence. This prevents an attacker who compromised a CI environment from forging signed releases — an increasingly relevant problem in supply chain attacks. Same logic applies to container images and internally distributed packages.

Unlock factor for internal tools — Admin panels, SRE portals, or sensitive CLIs can require FIDO2 authentication before executing destructive operations ("drain cluster", "delete namespace", "rotate CA"). This adds intentional friction exactly where it should exist: on irreversible actions.

Session compromise mitigation — Even if a machine is invaded or a terminal is open, the absence of the physical device prevents new authentications and critical operations. This limits attack impact and forces the adversary to act within a much more restricted window.

Personal identity anchor — The same YubiKey can be used for service login, code signing, SSH access, and data decryption. This consolidates identity, reduces attack surface, and simplifies the mental model: instead of dozens of distributed secrets, you have a single strong control point — that conveniently cannot be copied.

Programming Language Integration

Python

pip install yubikey-manager cryptography fido2
# yubikey-manager exposes the ykman API as a library

Go

go get github.com/go-piv/piv-go/piv
go get golang.org/x/crypto

Rust

# Cargo.toml
[dependencies]
yubikey = { version = "0.8", features = ["untested"] }
age = "0.10"
aes-gcm = "0.10"
rand = "0.8"
sha2 = "0.10"
rsa = { version = "0.9", features = ["sha2"] }

age + YubiKey (the modern approach): The age project is the modern successor to GPG for file encryption. The plugin age-plugin-yubikey integrates natively with PIV:

cargo install age-plugin-yubikey

Firmware Updates and Recent Changes

Yubico published relevant evolutions in the YubiKey 5 line with firmware 5.7: increased credential storage capacity, PIN management improvements, and enterprise-oriented features including enterprise attestation and CTAP 2.1 changes.

One point many people insist on ignoring: firmware is not user-upgradeable. If you want new firmware, you buy a new key.

References:

What I Consider "Good Use" of YubiKey in 2026

Good use is what reduces classes of attacks and improves your operations. Not what gives you more feeling of security.

For web accounts: Prioritize FIDO2/WebAuthn when available. The security leap is structural — you stop depending on a typeable secret and depend on authentication bound to the correct service.
For local Linux: If you do things that matter, requiring a token for sudo is one of the best cost/benefit ratios. Not because "nobody will become root," but because you cut the most common path of opportunistic attack.
For SSH: Hardware-backed auth changes the impact of credential exfiltration. Doesn't cure a compromised endpoint, but reduces the damage from passive leaks and makes identity harder to clone.
For personal/professional encryption: OpenPGP with subkeys by purpose and smartcard operation is the kind of discipline that prevents workarounds from becoming habits. Here the YubiKey is less "extra security" and more "minimum governance to not self-sabotage."

Non-negotiable rule: if you use one key, have two. The first is the one you carry. The second is the one that prevents "I lost an object" from becoming "I lost my digital identity."

Backup codes offline continue to exist for a reason.

Final Considerations

The YubiKey is not a silver bullet — it's a physical security layer that complements good practices. Points the pragmatic SRE needs to keep in mind:

Backup: Always have a second YubiKey configured. Losing your only key is a formative experience you don't want to have.
PIN vs Touch: Configure touch-policy=always for critical operations. Physical touch is what differentiates the YubiKey from a key file on disk.
Remote forwarding: For remote servers, usbip allows USB forwarding over the network. Alternative: use SSH agent forwarding with ssh-agent + FIDO2.
Auditing: The YubiKey serial is unique and can be used as an operator identifier in audit logs.
Revocation: Have a documented process for revoking and replacing keys when a YubiKey is lost or compromised.

The premise is simple: what's on the hardware cannot be exfiltrated by malware. An attacker who compromised your machine can steal your active session, but cannot open a new SSH connection, decrypt new files, or sign new commits without the physical token. This drastically reduces the exposure window.

Conclusion

The series started as 2FA and ended as identity and risk control. If you use YubiKey only to spit out OTP, you're using the most fragile mode of the ecosystem — useful, but far from the best. The value appears when you move authentication to FIDO2/WebAuthn where possible, use the hardware to reduce exfiltration in SSH, and treat cryptography (GPG) as something that deserves separation of functions and operation with less exposure.

This post is a commented index of the series, but also a reminder: security that depends on perfect user discipline is expensive and fails. Security that improves system design is cheaper in the long run and fails less embarrassingly.

References

YubiKey Series (Portuguese originals):

Cryptography (my blog):

Official Yubico:

Libraries and Tools:

GPG Cheatsheets:

Command Palette