我有一台运行 Debian Buster 的服务器，其根文件系统是不是已加密，但其他驱动器已加密。
[预计到达时间：所有 OS 系统目录（/var、、/home等/etc）都在未加密的根分区中。交换已加密，但每次启动时都会使用新的随机密钥以非交互方式创建，因此无需等待该密钥。]
我在 /etc/crypttab 和 /etc/fstab 中有一些条目来解密和挂载加密的“存储”驱动器，启动过程将无限期地等待密码到保存解密其他驱动器的密钥文件的微型加密分区。到目前为止一切顺利。密码提示符出现在物理连接的显示器上，我使用物理连接的键盘输入密码，然后启动继续。我安装了 OpenSSH 守护程序，并使用公钥身份验证在服务器启动后连接到服务器进行各种管理。
现在我希望能够通过 ssh 远程解锁这些 LUKS 设备。由于 root 是不是其中一个加密文件系统，我认为没有必要进行整个“dropbear+busybox in initramfs”业务，我认为这会相对简单。
sudo systemctl edit ssh.service并添加以下几行：
[Unit]
Before=cryptsetup-pre.target
[Install]
WantedBy=cryptsetup-pre.target
这应该会让 systemd 在开始解密本地磁盘之前先启动 sshd，对吗？（我选择WantedBy而不是RequiredBy，因为如果 sshd 没有按预期启动，我不希望 systemd 让 cryptsetup 失败。）
sudo systemctl daemon-reload不会报错，并按cat /etc/systemd/system/ssh.service.d/override.conf预期显示这四行。重新启动时，密码提示出现（预期），但所有通过 ssh 进入服务器的尝试都返回No route to host，因此显然 ssh.service 没有先启动。
我尝试更改覆盖以指定 ssh 是 WantedBy 并且位于 systemd 生成的[email protected]单元之前。有趣的是，这导致没有 ssh和没有密码提示，所以启动一直挂起，我不得不从恢复媒体启动并删除覆盖。这没什么用，但至少有明显的效果。也许我在某处创建了循环依赖？密码提示似乎确实会出现真的在启动序列的早期。
我接下来要做什么？是否可以覆盖 systemd 生成的 cryptsetup 单元以将其提供给Wants=？After=如果ssh.service可能，有什么理由认为会得到更好的结果？在 /etc/ 下为该密钥库分区编写自己的单元并删除相应的 inittab 和 fstab 条目是否有意义？简而言之，有没有什么合理的方法可以让它工作，或者我应该放弃这条路，最终在 initramfs 中使用 dropbear+busybox？
PS. 我曾考虑过将加密驱动器设置为“noauto”，但我已将这些磁盘上的虚拟机配置为在启动过程的稍后阶段自动启动，因此我更希望远程解锁能够正常工作。
答案1
使用cryptsetup.target或cryptsetup-pre.target对我来说不起作用，但我不知道为什么。
它致力于创建覆盖[email protected]：
# /etc/systemd/system/[email protected]/myservice.conf
[Unit]
Wants=myservice.service
After=myservice.service