我在 Debian Jessie 上的 systemd 下使加密的多磁盘根文件系统可靠启动时遇到了很多问题,而只需输入一次密码。以前,我在 Debian 中通过decrypt_derived
对除第一个设备之外的每个设备使用 /etc/crypttab 中的密钥脚本来处理此问题,效果很好。
然而,当引入 systemd 时,这并不能很好地发挥作用。systemd-cryptsetup-generator
不处理键盘脚本,当试图查找有关如何解决此问题的更多信息时,我只发现对一些自定义的模糊引用密码代理在一个电子邮件来自一位 systemd 开发人员,他只给出了无用的建议:“很容易编写额外的代理。遵循的基本算法如下所示”然后列出了需要采取的 13 个步骤。显然不适合最终用户。
在 Debian 中,我通过使用几个内核选项来让它在某种程度上发挥作用,这些选项告诉 systemd/etc/crypttab
在启动过程中忽略它,或者完全忽略它。 Debianupdate-initramfs
会将密钥脚本复制到 initramfs 并在 systemd 接管之前解锁设备,但我发现这会导致以后出现问题,因为 systemd 现在没有任何用于解密设备的单元文件,因此依赖它们的挂载有时似乎会挂起或被延误。这个问题的一个地方是尝试挂载 btrfs 子卷时;它们从与 root 相同的物理设备安装,但 systemd 不知道设备已经解锁,并在启动时停止。
TL;DR - 我的实际问题:
systemd 如何处理跨多个设备(无论是 btrfs 系统、LVM 镜像等)的加密根文件系统,其中只需输入一次密码?我认为这不是一个非常不寻常的情况,所以希望有一种方法可以做到这一点。
我想到了一些可能的解决方案:
- 包含密钥文件的微小加密分区,在 root 之前解锁。根设备将引用此密钥文件。我该如何将其告诉 systemd?
- 在 initramfs 中运行的某种缓存密码代理,它会记住密码并在启动时将其传递给所有需要它的设备。
- 有人已经编写了一个模拟解密_派生的 systemd 代理。我如何将其集成到我的启动程序中?
我确实只运行 Debian,但在尝试了几天寻找问题的解决方案之后,我觉得这可能是一个更系统范围的问题。
答案1
这是一个众所周知的问题,目前还没有解决方案。
在 Debian(和其他系统)上,由于并行进程和各种测试,systemd 无法组装加密的 BTRFS 数组。 BTRFS 阵列的所有卷都必须存在才能安装(正确),但由于 BTRFS 阵列的所有卷都具有相同的 UUID(根据设计),systemd 会尝试安装它打开的第一个卷,而无需等待其他的(这会暴露相同的 UUID,让 systemd 更加困惑)。
目前,在 Debian 上使用加密 BTRFS 卷的唯一方法是不是使用 systemd(包sysvinit-core
、systemd-shim
等)。没有可能的“systemd 方式”。
答案2
现在这个问题有一个解决方案(至少在 Ubuntu 18.04+ 中,所以我假设是 Debian 和 CentOS-7)。描述这里。引用:
Systemd ...将解锁所有额外的 LUKS 分区如果
- 您要解锁的所有分区都使用相同的密码
- 第一次输入正确的根分区密码。如果输入错误,则需要为每个其他 LUKS 分区重新输入