我的机器有一个 SSD，我在其中安装了系统，还有一个 HDD，我用它来存储大型和/或不常用的文件。两者都已加密，但我选择对它们使用相同的密码。 SSD 安装在/，HDD 安装在/usr/hdd（每个用户都有一个目录，并且可以根据需要从主目录进行符号链接）。
当系统启动时，它会立即询问 SSD 的密码，几秒钟后询问 HDD 的密码（它是自动安装的）。鉴于两个密码相同，是否有办法将系统配置为仅询问一次？
答案1
基于 Debian 的发行版：
Debian 和 Ubuntu 提供密码缓存脚本解密密钥控制和密码设置包裹。
解密密钥控制脚本为多个加密的 LUKS 目标提供相同的密码，从而避免您多次输入密码。它可以在以下位置启用：密码表有keyscript=decrypt_keyctl选项。相同的密码用于具有相同标识符的目标密钥文件字段。启动时，每个标识符都会询问一次密码。
一个例子密码表：
<target> <source> <keyfile> <options>
part1_crypt /dev/disk/... crypt_disks luks,keyscript=decrypt_keyctl
part2_crypt /dev/disk/... crypt_disks luks,keyscript=decrypt_keyctl
该decrypt_keyctl脚本取决于keyutils软件包（仅建议，因此不一定安装）。
更新后密码表，您还必须更新 initramfs 才能应用更改。使用update-initramfs -u。
解密_keyctl 的完整自述文件位于/usr/share/doc/cryptsetup/README.keyctl
不提供的发行版解密密钥控制脚本：
如果解密密钥控制您的发行版未提供，可以使用加密根文件系统中的密钥文件解锁设备。当根文件系统可以在任何其他加密设备之前解锁和安装时。
LUKS 支持多个键槽。如果密钥文件不可用/丢失，您可以选择使用密码解锁设备。
使用随机数据生成密钥，并将其权限设置为所有者只读，以避免泄露。请注意，密钥文件需要位于首先解锁的根分区上。
dd if=/dev/urandom of=<path to key file> bs=1024 count=1 chmod u=rw,g=,o= <path to key file>将密钥添加到您的 LUKS 设备
cryptsetup luksAddKey <path to encrypted device> <path to key file>配置密码表使用密钥文件。第一行应该是根设备，因为设备按照与中列出的相同顺序解锁密码表。对关键文件使用绝对路径。
<target> <source> <keyfile> <options> root_crypt /dev/disk/... none luks part1_crypt /dev/disk/... <path to key file> luks
答案2
另一种选择是使用/lib/cryptsetup/scripts/decrypt_derived脚本，它也是 Debian/Ubuntu 中 cryptsetup 的一部分。
您可以使用一个磁盘的卷密钥作为第二个磁盘的附加密码，而不是缓存密钥。这需要向第二个（和第三个等）加密磁盘添加第二个密码，但 LUKS 支持这一点。因此，如果您的多个加密磁盘不使用相同的密码，此解决方案也适用。
将密钥从 sda6crypt 添加到 sda5 的示例：
添加 sda6crypt 的卷密钥作为 sda5 的附加密码：
mkfifo fifo
/lib/cryptsetup/scripts/decrypt_derived sda6crypt > fifo &
cryptsetup luksAddKey /dev/sda5 fifo
rm fifo
配置sda5crypt自动解锁/etc/crypttab
ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab
这使用命名管道 ( fifo) 来传递密钥，以避免将卷密钥存储在磁盘上的临时文件中。
该keyscript选项仅在crypttab由 Debian 原始 cryptsetup 工具处理时才有效，systemd 重新实现当前不支持它。如果您的系统使用 systemd（这是大多数系统），则需要initramfs在 systemd 启动之前选择通过 cryptsetup 工具强制在 initrd 中进行处理。
答案3
鉴于 @sebasth 上面提到的错误，这是我在 debian 上的解决方法。
我的设置略有不同。我有一个加密的根分区和一堆 raid 磁盘。对我来说，我必须向 crypttab 添加一个 initramfs 选项：
<target> <source> <keyfile> <options>
part1_crypt /dev/disk/... crypt_disks plain,cipher=aes-xts-plain64,keyscript=decrypt_keyctl,initramfs
part2_crypt /dev/disk/... crypt_disks plain,cipher=aes-xts-plain64,keyscript=decrypt_keyctl,initramfs
这告诉 update-initramfs 我希望将这些 crypttab 条目安装在 initramfs 中。我通过运行检查了我的 crypttab
cryptdisks_start part1_crypt
cryptdisks_start part2_crypt
请注意，我的 raid 磁盘是普通的 dm-crypt。这意味着我无法使用解决 systemd keyscript bug 的 luks keyfile 方法。对于普通 dm-crypt，我必须以明文形式存储密码。
update-initramfs运行之前必须安装 keyutils 软件包并安装加密磁盘；否则会抛出错误。当我的 initramfs 构建时，我必须寻找以下几行：
update-initramfs -u -v | grep 'keyctl'
显示以下两个文件：
/bin/keyctl
cryptkeyctl
被添加到 initramfs 中。
最后，我不得不禁用 systemd 处理我的 crypttab，以处理上面提到的错误：systemd 不支持 crypttab 中的 keyscript 选项。为此，我添加了内核选项
GRUB_CMDLINE_LINUX_DEFAULT="quiet luks.crypttab=no"
到 /etc/default/grub 并运行update-grub. systemd 现在忽略 crypttab，所有加密分区都加载到 initramfs 中。
因为我有一个加密的根分区，所以 cryptroot 似乎没有缓存我的密钥。这意味着我必须输入两次密码；一个用于根分区，一个用于我的 raid 阵列。
答案4
以防万一这对任何人都有帮助：现在这应该发生在大多数基于 systemd 的系统上。
在带有 Plymouth 的 Fedora 上，这种行为会在默认设置下自动发生。
* The "ask-password" framework used to query for LUKS harddisk
passwords or SSL passwords during boot gained support for
caching passwords in the kernel keyring, if it is
available. This makes sure that the user only has to type in
a passphrase once if there are multiple objects to unlock
with the same one. Previously, such password caching was
available only when Plymouth was used; this moves the
caching logic into the systemd codebase itself. The
"systemd-ask-password" utility gained a new --keyname=
switch to control which kernel keyring key to use for
caching a password in. This functionality is also useful for
enabling display managers such as gdm to automatically
unlock the user's GNOME keyring if its passphrase, the
user's password and the harddisk password are the same, if
gdm-autologin is used.
https://lists.freedesktop.org/archives/systemd-devel/2015-October/034509.html