systemd/man/tpm2-crypttab.sh

# SPDX-License-Identifier: MIT-0

# Enroll the TPM2 security chip in the LUKS2 volume, and bind it to PCR 7
# only. Replace /dev/sdXn by the partition to use (e.g. /dev/sda1).
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/sdXn

# Test: Let's run systemd-cryptsetup to test if this worked.
sudo /usr/lib/systemd/systemd-cryptsetup attach mytest /dev/sdXn - tpm2-device=auto

# If that worked, let's now add the same line persistently to /etc/crypttab,
# for the future.
sudo bash -c 'echo "mytest /dev/sdXn - tpm2-device=auto" >>/etc/crypttab'

# Depending on your distribution and encryption setup, you may need
# to manually regenerate your initramfs to be able to use
# a TPM2 security chip to unlock the partition during early boot.
# More information at https://unix.stackexchange.com/a/705809
# On Fedora based systems:
sudo dracut --force
# On Debian based systems:
sudo update-initramfs -u
man: change license of examples to MIT-0 Quoting Richard Fontana in [1]: CC0 has been listed by Fedora as a 'good' license for code and content (corresponding to allowed and allowed-content under the new system). We plan to classify CC0 as allowed-content only, so that CC0 would no longer be allowed for code. Over a long period of time a consensus has been building in FOSS that licenses that preclude any form of patent licensing or patent forbearance cannot be considered FOSS. CC0 has a clause that says: "No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document." (The trademark side of that clause is nonproblematic from a FOSS licensing norms standpoint.) The regular Creative Commons licenses have similar clauses. For the case of our documentation snippets, patent issues do not matter much. But it is always nicer to have a license that is considerred acceptable without any further considerations. So let's change the license to the (now recommended replacement) MIT-0. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NO7KGDNL5GX3KCB7T3XTGFA3QPSUJA6R/ Using 'git blame -b' and 'git log -p --follow', I identified the following folks as having made non-trivial changes to those snippets: Lennart Poettering Tom Gundersen Luca Bocassi Zbigniew Jędrzejewski-Szmek Thomas Mühlbacher Daan De Meyer I'll ask for confirmation in the pull request. 2022-10-26 06:02:14 +00:00			`# SPDX-License-Identifier: MIT-0`
man: add licenses to all files that lack one Documentation is licensed under LGPL-2.1-or-later. Scripts are MIT to facilitate reuse. Examples are relicensed to CC0-1.0 to maximise copy-and-paste for users, with permission from authors. 2021-10-01 10:44:33 +00:00
man: document new features 2020-12-07 16:18:52 +00:00			`# Enroll the TPM2 security chip in the LUKS2 volume, and bind it to PCR 7`
			`# only. Replace /dev/sdXn by the partition to use (e.g. /dev/sda1).`
			`sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/sdXn`

			`# Test: Let's run systemd-cryptsetup to test if this worked.`
			`sudo /usr/lib/systemd/systemd-cryptsetup attach mytest /dev/sdXn - tpm2-device=auto`

			`# If that worked, let's now add the same line persistently to /etc/crypttab,`
			`# for the future.`
test: drop whitespace after shell redirection operators (The one case that is left unchanged is '< <(subcommand)'.) This way, the style with no gap was already dominant. This way, the reader immediately knows that ' < ' is a comparison operator and ' << ' is a shift. In a few cases, replace custom EOF replacement by just EOF. There is no point in using someting like "_EOL" unless "EOF" appears in the text. 2023-02-05 20:41:24 +00:00			`sudo bash -c 'echo "mytest /dev/sdXn - tpm2-device=auto" >>/etc/crypttab'`
Add recommended initramfs regeneration I recently tried adding a FIDO2-Device as an unlocking method to the LUKS2 partition containing my Fedora install. When trying to do this, I stumbled upon the here edited man files detailing how to do this. I however could not unlock my partition with my FIDO2-Device after editing /etc/crypttab and rebooting. As I found out after a while, I needed to regenerate / update my currently running / used initramfs (https://unix.stackexchange.com/a/705809). This would have most likely solved itself for me with the next kernel update install (as far as I understand). So I propose changing the files edited here to recommend or at least inform the user about this. 2023-09-21 21:52:04 +00:00
			`# Depending on your distribution and encryption setup, you may need`
			`# to manually regenerate your initramfs to be able to use`
			`# a TPM2 security chip to unlock the partition during early boot.`
			`# More information at https://unix.stackexchange.com/a/705809`
			`# On Fedora based systems:`
			`sudo dracut --force`
			`# On Debian based systems:`
			`sudo update-initramfs -u`