Linux Authentication and Boot Trust Labs

FIDO and Secure Boot Lab Materials

These labs give learners a safe, repeatable environment to practice Linux security changes that are easy to misunderstand on a daily-use machine: hardware-backed authentication, PAM control flow, recovery planning, privilege separation, and Secure Boot trust decisions.

Why these labs exist

Modern Linux authentication is not just a password prompt. FIDO2/U2F tokens, PAM modules, local privilege escalation, display managers, recovery paths, and boot-chain protections all interact. These materials are intended to help learners make those interactions visible, testable, and reversible before they attempt similar changes on production or personal systems.

Expected outcomes

  • Build the Linux fundamentals — shell, filesystem, permissions, and PAM — these labs assume, whether starting from scratch or refreshing the basics.
  • Understand where FIDO2/U2F fits in Linux login, service authentication, and sudo.
  • Practice PAM edits with validation, rollback, and recovery steps.
  • Observe how Secure Boot changes the trust boundary before the OS starts.
  • Leave with a working mental model — and a self-audit checklist — for safer authentication and boot-trust changes.
Start here

Using the VirtualBox lab VM

Download VM

A known-good starting point for the FIDO lab path: Debian FIDO VM v4.4, a virtual appliance that gives learners a repeatable baseline so they can explore authentication changes without risking their primary workstation. Download it, import it, and take your first snapshot before making any changes.

Verify the SHA-256 hash, import into your hypervisor, boot once, log in as vboxuser, and take a Clean Import snapshot before beginning. Only tested under VirtualBox.

Version 4.4 2.5 GB download Debian
Verify download sha256sum "fido_vm_v4.4_[20260715-1101]-baseline.ova"
c0b575bc93c202a28bb67f6b9d40c32d009aaa74eddb40d4923a806737aee566
Import appliance

Import steps

These steps follow VirtualBox, the hypervisor the appliance was tested under.

  1. Download the .ova file above.
  2. Open Oracle VirtualBox.
  3. Select File → Import Appliance.
  4. Choose the downloaded .ova file.
  5. Review the appliance settings and select Finish.
  6. Boot the VM once to confirm it reaches the login screen.
  7. Power it off and create a snapshot named Clean Import.

The VirtualBox appliance import dialog shows a MAC address policy option — this is standard VirtualBox UI. No MAC addresses are embedded in the .ova file, so all three policy choices produce the same outcome: new addresses are generated on import.

Initial access

Initial VM account

The imported VM starts with one local account.

AccountPasswordPurpose
vboxuserqazwsx Initial local account; member of the sudo group.
rootdisabled Use sudo from vboxuser for initial administration.
The breakglass account is not pre-created. Create it early, keep it password-only, and do not convert it to FIDO-only. It is the recovery path when a PAM edit or experiment fails.
Recovery discipline

Use snapshots aggressively

These labs intentionally modify authentication, boot, and trust configuration. Snapshots are part of the lab procedure.

  • Clean Import — immediately after importing and first boot validation.
  • Before FIDO Changes — before editing PAM, mapping tokens, or locking passwords.
  • Before Privilege Separation — before separating login and sudo token behavior.
  • Completed Lab — after verified expected behavior.
Secure Boot behavior may differ between VirtualBox and physical hardware. The Secure Boot lab was tested on a physical machine and may be better taught on physical devices when firmware behavior matters.
Sub-site HTML

Linux 101

A guided tour of the Linux ecosystem for anyone who's shakier on the basics than the primer assumes — distro choice, desktop environments, the command line, and a real worked example of a full post-install setup with the reasoning behind every choice.

16 pages No VM required Separate sub-site
Open Linux 101 →
Primer HTML

Linux Command & File Reference

Recommended first reading before the hands-on labs. A guided, no-VM tour of the commands and system files that run and secure a Linux machine — the shell, filesystem, users and groups, permissions, PAM, services, processes, logs, and network exposure — each with what it prints and why it matters to a defender. The identity, permissions, and PAM sections are the exact foundation the FIDO and Secure Boot labs build on.

Read-through No VM required 13 sections Linux Mint / Debian
Open primer →
Checklist HTML

Linux Hardening Checklist

An interactive self-audit that mirrors the primer section by section — accounts, password and PAM policy, sudo, permissions and SUID, software, services, scheduled tasks, network and firewall, SSH, and logging. Each of the 43 checks expands to the command that verifies it and what a good result looks like. Progress is saved in the browser, and it prints to a clean paper worksheet.

Self-audit Interactive 43 checks Maps to the primer
Open checklist →
Primer HTML

PAM Primer

A focused, no-VM deep dive into Pluggable Authentication Modules: rule anatomy, the required/requisite/sufficient/optional control keywords, the shared common-* stack files, pam_unix and pam_faillock, how to edit PAM without locking yourself out, reading journalctl to watch it happen live, a preview of pam_u2f — the exact module the FIDO lab adds to the stack — and what pam_systemd / loginctl do once a login has already succeeded.

Read-through No VM required 10 sections Bridges to the FIDO Lab
Open PAM primer →
Follow-on FIDO Lab HTML

FIDO Privilege Separation Lab v0.1

A follow-on lab after the initial FIDO login build. Learners separate normal login identity from privileged authorization: the blue key logs into the system, while a separate yellow key is required for sudo. Covers PAM service separation, sudo-specific policy, credential caching, testing, rollback, and recovery planning.

Version 0.1 Guided lab Linux PAM FIDO2 / U2F Privilege separation
Open lab guide →
FIDO SSH Lab HTML

FIDO SSH Authentication Lab v1.0

A follow-on lab that moves the hardware key from local login to remote access. Learners create a resident sk-ed25519 key on the token — the private key never leaves the hardware — and enforce PIN + touch for SSH with verify-required on both client and server. No PAM changes, so rollback is simple. Ties back to the blue/yellow key model: the login key versus the SSH key.

Version 1.0 Guided lab OpenSSH FIDO2 / sk-ed25519
Open lab guide →
Secure Boot Lab HTML

Secure Boot Lab v4.5

The current Secure Boot, TPM, and full-disk encryption lab. Covers UEFI Secure Boot, LUKS2 with Clevis TPM2 auto-unlock, PCR policy, MOK enrollment, and kernel update re-enrollment procedures. Includes reference to the automated toolset.

Tested on physical hardware. Secure Boot and TPM behavior depend heavily on firmware — teach on physical devices where possible.

Version 4.5 Guided lab UEFI / TPM2 LUKS2 / Clevis Physical hardware tested
Open lab guide →
Secure Boot Guide HTML

Kernel Update PCR Guide v4.5

Step-by-step procedure for performing a kernel update with temporary PCR relaxation and strict policy re-enrollment. Covers which PCRs change, slot transition commands, stable vs runtime PCR values, and a mapping of each manual step to its automation equivalent.

Version 4.5 Reference guide TPM2 / Clevis PCR policy
Open guide →
Secure Boot Manual HTML

TPM Update Automation Manual v4.5

Installation, testing, and operations manual for the kernel-update-tpm automated toolset. Covers install, verification, APT hook operation, sentinel file anatomy, monitoring, and six recovery procedures keyed to specific failure modes.

Version 4.5 Operations manual TPM2 / Clevis APT hook
Open manual →

VM Appliances

  • fido_vm_v4.4_[20260714-1447]-baseline.ova 2.5G no longer hosted d1a5bd0d98e6b122aabe49a911cb86b8b1025dcd2673774f456f22111bd9b0ef
  • fido_vm_v4.3_[20260617-2039]-baseline.ova 2.9G no longer hosted f03321f430fe5151bba47a3a827a6db5d43b9c7509da09736a7bc53596463dd1