Not to reboot a LUKS encrypted system from afar, unprepared

There is a Workstation in the office which I wanted to upgrade to the latest Fedora Workstation version 37. Right after following the dnf documentation on upgrades and issuing the dnf system-upgrade reboot command I remembered that the Workstation uses LUKS disk encryption and won’t do the upgrade without me entering the passphrase at boot. So how to fix that in the future?

The device does not have a TPM2 chip, as it is rather old (8 years or so). So automatic disk-decryption using the TPM2 chip is not an option. Before you ask: it is possible to configure the TPM2 and Secure Boot in a way that upgrades are OK from a tempering protection perspective if we don’t look at PCR 7 too aggressively. An alternative option with a similar notion to this is using a TANG server which a machine can talk to in a trusted network to receive a decryption key. Have a look at this nice article from RedHat about that.

An alternative to this is configuring initramfs via dracut to spawn an OpenSSH server with a simple prompt for the passphrase after login. This is what I do in my infrastructure (ansible role) as I usually don’t have TPM2 chips available while remote access at boot is a thing. It installs the dracut-sshd module into the initramfs. This obviously is not as convenient and scalable as auto-decryption but it does suffice.

So to sum this up: if I don’t have remote access to the machine at boot I’d like it to unlock it’s encrypted disk automatically either through a bound TPM2 chip and Secure Boot or using a TANG server. If I got access to the net it is sufficient for me to have sshd run in the initramfs.