У меня есть сервер, работающий под управлением Debian Buster, корневая файловая система которогонетзашифрованы, но другие диски зашифрованы.
[Расчетное время прибытия:Все системные каталоги ОС ( /var, /home, /etc, и т. д.) находятся в незашифрованном корневом разделе. Раздел подкачки зашифрован, но он создается неинтерактивно с новым случайным ключом при каждой загрузке, поэтому ничего не задерживается в ожидании этого.]
У меня есть записи в /etc/crypttab и /etc/fstab для расшифровки и монтирования зашифрованных дисков «хранилища», и процесс загрузки будет бесконечно ждать парольной фразы для крошечного зашифрованного раздела, который содержит ключевые файлы, расшифровывающие другие диски. Пока все хорошо. Запрос на парольную фразу появляется на физически подключенном мониторе, я ввожу парольную фразу с помощью физически подключенной клавиатуры, и загрузка продолжается. У меня установлен демон OpenSSH, и я использую аутентификацию с открытым ключом для подключения к серверу для всех видов администрирования после его загрузки.
Теперь я хочу иметь возможность удаленно разблокировать эти устройства LUKS через ssh. Поскольку root — этонетодна из зашифрованных файловых систем, я не вижу никакой необходимости во всем этом "dropbear+busybox в initramfs", и я подумал, что это будет относительно просто.
sudo systemctl edit ssh.serviceи добавьте следующие строки:
[Unit]
Before=cryptsetup-pre.target
[Install]
WantedBy=cryptsetup-pre.target
Это должно заставить systemd перетасовать все так, чтобы запустить sshd перед началом любой расшифровки локальных дисков, верно? (Я выбрал , потому что WantedByне RequiredByхочу, чтобы systemd «сбойнул» cryptsetup, если sshd не запустится должным образом.)
sudo systemctl daemon-reloadне жалуется и cat /etc/systemd/system/ssh.service.d/override.confпоказывает эти четыре строки, как и ожидалось. При перезагрузке появляется запрос на ввод парольной фразы (ожидается), но все попытки подключиться к серверу по ssh возвращаются с No route to host, так что очевидно, что ssh.service не был запущен первым.
Я попробовал изменить переопределение, чтобы указать, что ssh — WantedBy и идет Before сгенерированного systemd [email protected]блока. Интересно, что это привело к отсутствию sshине было запроса на ввод пароля, поэтому загрузка просто зависла навсегда, и мне пришлось загрузиться с носителя для восстановления и удалить переопределение. Это не совсем помогло, но, по крайней мере, это имело заметный эффект. Может быть, я создал где-то циклическую зависимость? Запрос на ввод пароля, похоже, приходитДействительнов начале последовательности загрузки.
Каковы мои дальнейшие действия? Возможно ли переопределить сгенерированный systemd модуль cryptsetup, чтобы указать его Wants=и After=ссылки на ssh.service? Если это возможно, есть ли основания полагать, что это даст лучшие результаты? Имеет ли смысл писать собственные модули в /etc/ для этого раздела хранилища ключей и удалять соответствующие записи inittab и fstab? Короче говоря, есть ли какой-либо отдаленно разумный способ заставить это работать, или мне следует отказаться от этого пути и все-таки использовать dropbear+busybox в initramfs?
P.S. Я думал просто сделать зашифрованные диски «noauto», но у меня есть виртуальные машины на этих дисках, настроенные на автозапуск в процессе загрузки, поэтому я бы предпочел, чтобы работала удаленная разблокировка.
решение1
Использование cryptsetup.targetor cryptsetup-pre.targetу меня не сработало, но я не знаю почему.
Он работал над созданием наложения для [email protected]:
# /etc/systemd/system/[email protected]/myservice.conf
[Unit]
Wants=myservice.service
After=myservice.service