Typing a LUKS passphrase at every boot gets old on a headless box, and systemd-cryptenroll can hand that job to your TPM2 chip instead. You will enrol a TPM2-based method for an existing LUKS2 volume, bind it to Secure Boot state through PCR 7, and prepare the matching /etc/crypttab entry. The installed command here is systemd 255 from the systemd package.
Allow about 20 minutes, including one reboot test. You need root access, a TPM2 device, an existing LUKS2 volume, and a working passphrase or recovery key that you will keep until the new path has been tested. This guide changes LUKS metadata and boot-time volume configuration, so do it from local or out-of-band console access rather than during an unattended remote session.
Use the block device that contains the LUKS2 header, not the mounted filesystem inside it. Assign it to a shell variable so every later command is easy to review:
$ LUKS_DEVICE=/dev/disk/by-uuid/REPLACE-WITH-LUKS-UUID
$ sudo cryptsetup luksDump "$LUKS_DEVICE" | sed -n '1,24p'
$ systemd-cryptenroll --version
systemd 255The UUID placeholder is deliberate. Find the real value with lsblk -f or your existing /etc/crypttab entry. The dump should identify a LUKS2 header. systemd-cryptenroll stores token metadata in the LUKS2 JSON area and does not support older LUKS formats.
Checkpoint: do not continue if the device is wrong, the header is not LUKS2, or you cannot open the volume with the existing method. Keep that existing method available as your recovery route.
This is a read-only discovery command. It does not enrol anything:
$ systemd-cryptenroll "$LUKS_DEVICE" --tpm2-device=list
/dev/tpmrm0The output is host-specific. If the machine has exactly one suitable TPM2 device, auto can select it. If the list is empty, stop and investigate firmware TPM settings, device permissions, or the systemd TPM support installed on this host. Do not guess a device node.
Also check the command's own option spelling before using a copied example:
$ systemd-cryptenroll --help | grep -E -- '--tpm2-(device|pcrs)|--wipe-slot'Enrolment writes a new key slot and token record, so this command requires elevated privileges. The existing passphrase is normally requested first. Have it ready:
$ sudo systemd-cryptenroll "$LUKS_DEVICE" \
--tpm2-device=auto \
--tpm2-pcrs=7On success the command exits with status 0 and returns to the shell. It may prompt for the existing passphrase and, depending on the TPM and policy, other input. The explicit --tpm2-pcrs=7 makes the policy visible in the command. In systemd 255, omitting this option also defaults to PCR 7 for a TPM2 enrolment.
PCR 7 represents Secure Boot policy. A later change to Secure Boot state or its relevant firmware certificates can therefore make this TPM2 path unavailable until the policy is addressed. This is a security boundary, not a generic convenience setting. If you need a different PCR design, document it before enrolling and understand how firmware and bootloader changes will affect recovery.
Checkpoint: verify that a new TPM2 token exists without removing anything:
$ sudo cryptsetup luksDump "$LUKS_DEVICE" | grep -A8 -B2 -i tpm2The exact dump format varies. A non-zero exit from grep means it found no matching text, not that the volume has been damaged. Re-run the full dump and inspect the LUKS2 token and keyslot sections before trying the command again.
Enrollment alone does not tell the boot-time cryptsetup service to use the TPM2 token. Edit the existing line for this volume in /etc/crypttab as root, preserving its mapper name and device:
sudoedit /etc/crypttabAdd tpm2-device=auto to the options field. For example, a line may look like this:
vault /dev/disk/by-uuid/REPLACE-WITH-LUKS-UUID - tpm2-device=autoThe dash is the key-file field in this example. Do not replace unrelated options already used by your system. The option belongs in crypttab, while --tpm2-device=auto belongs to the enrolment command.
Check the saved line and the generated service configuration:
$ grep -v '^[[:space:]]*#' /etc/crypttab
$ sudo systemctl daemon-reloaddaemon-reload is not a reboot and does not open the volume by itself. If this is the root volume, do not experiment by stopping its cryptsetup service on a running machine.
Save the current configuration and make sure you can reach a console or use your existing remote recovery arrangement. Then reboot during a maintenance window:
$ sudo systemctl rebootAt boot, the system should offer the TPM2 path according to the generated cryptsetup configuration. PCR 7 must match the state recorded by the enrolment. If the TPM2 attempt fails, use the existing passphrase or recovery key. Once booted, check the mapper and journal:
$ findmnt /dev/mapper/vault
$ sudo journalctl -b -u [email protected] --no-pagerReplace vault with the crypttab mapper name. A successful test means the intended volume is mounted or otherwise active and the journal contains a successful activation rather than merely showing that a prompt appeared.
Warning: slot wiping is destructive. It removes ways to open the volume, and wiping every usable slot can make the data inaccessible. Keep at least one tested recovery method. If you are replacing older TPM2 enrolments, combine the new enrolment and wipe so the new slot is created first:
$ sudo systemd-cryptenroll "$LUKS_DEVICE" \
--tpm2-device=auto \
--tpm2-pcrs=7 \
--wipe-slot=tpm2That operation leaves the newly added slot out of the wipe. It still changes persistent encryption metadata, so retain a backup and the existing passphrase until the replacement has been tested through a complete reboot. Never use --wipe-slot=all as a routine cleanup. The program refuses some attempts to remove every slot, but that safeguard is not a substitute for your recovery plan.
To undo the configuration change, restore the previous /etc/crypttab line and reload systemd. To undo a slot wipe, there is no general restore command: enrol the required method again, using a still-working passphrase, recovery key, or hardware token.
cryptsetup luksDump before writing./etc/crypttab contains the matching tpm2-device=auto option.