我有一台運行 Debian Buster 的伺服器，其根檔案系統是不是已加密，但其他磁碟機已加密。
[預計抵達時間：所有作業系統目錄（/var、/home、/etc等）都位於未加密的根分割區中。交換是加密的，但它是在每次啟動時使用新的隨機密鑰以非交互方式創建的，因此不會有任何等待。 ]
我在/etc/crypttab 和/etc/fstab 中有條目來解密和安裝加密的「儲存」驅動器，引導過程將無限期地等待保存用於解密其他驅動器的密鑰檔案的微小加密分割區的密碼。到目前為止，一切都很好。實體連接的顯示器上會出現密碼短語提示，我使用實體連接的鍵盤輸入密碼短語，然後啟動繼續。我安裝了 OpenSSH 守護程序，並在啟動後使用公鑰身份驗證連接到伺服器進行各種管理。
現在我希望能夠透過 ssh 遠端解鎖這些 LUKS 設備。由於根是不是作為加密檔案系統之一，我認為不需要整個「initramfs 中的 dropbear+busybox」業務，而且我認為這相對簡單。
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 嗎？
附言。我曾想過將加密驅動器設置為“noauto”，但我在這些磁碟上配置了虛擬機，以便在啟動過程中稍後自動啟動，所以我真的寧願讓遠端解鎖工作。
答案1
使用cryptsetup.targetorcryptsetup-pre.target對我不起作用，但我不知道為什麼。
它致力於為以下內容創建覆蓋層[email protected]：
# /etc/systemd/system/[email protected]/myservice.conf
[Unit]
Wants=myservice.service
After=myservice.service