LUKS keyscript проигнорированный … просит пароль
Позвольте мне начать путем высказывания, что я не плохо знаком с LUKS. Я настроил LUKS с keyscripts многочисленными временами с и без LVM. Я не уверен, что на самом деле продолжается здесь все же. У меня есть система, которая имеет единственный зашифрованный раздел. Мой диск организован следующим образом:
# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 128G 0 disk └─sda1 8:1 0 128G 0 part ├─vg0-root 253:1 0 20G 0 lvm / ├─vg0-secure 253:6 0 100M 0 lvm │ └─secure 253:7 0 98M 0 crypt /root/secure └─vg0-swap 253:4 0 1G 0 lvm [SWAP]
Мой /etc/crypttab файл выглядит примерно так
# UUID is not required here since the path to the LV won't change secure /dev/vg0/secure none luks,keyscript=/lib/cryptsetup/scripts/insecure
Мой /lib/cryptsetup/scripts/insecure файл является исполняемым файлом и выглядит примерно так
#!/bin/sh
# My actual file looks somewhat different because it dumps the key file with dd.
# This accomplishes virtually the same thing though.
echo -n "my-encryption-password"
Я работал update-initramfs -k all -u неоднократно после конфигурирования crypttab и помещения моего keyscript файла на месте.
Насколько я могу сказать, мой файл сценария даже не становится скопированным в initrd.img файл. Теперь, когда я думаю об этом, я не думаю, что это скопировать в initrd.img файл, так как корневой раздел не шифруется, и файл сценария должен быть легкодоступным оттуда.
После перезагрузки система видит запись от crypttab и просит пароль (который в моем случае на самом деле не существует, потому что единственный ключ является файлом ключей, полным случайных битов) вместо того, чтобы использовать keyscript для разблокирования раздела LUKS. Я попытался вынуть LUKS из LVM и поместить его на sda2, и результатами было то же. Я также знаю, что keyscript работает потому что cryptsetup luksOpen /dev/vg0/secure secure -d - <<< "$(/lib/cryptsetup/scripts/insecure)" работы как очарование и дешифруют мой раздел LUKS.
Я попробовал это в Помощнике Ubuntu 16.04.2 и Ubuntu 16.04.2 с теми же результатами. Я использовал keyscripts прежде без любой проблемы. Единственная разница была то, что, в прошлом мой / раздел всегда шифровался. Если бы кто-либо может пролить некоторый свет, я ценил бы его. Я только хочу очень небольшой зашифрованный раздел, потому что я планирую клонирование этой системы, и я не хочу клонировать его со всем / зашифрованный раздел.
ОБНОВЛЕНИЕ 26.04.2017
В рытье через журналы я нашел строку со следующей ошибкой, которая не имеет никакого смысла. С тех пор, когда 'keyscript =/path/to/script' неизвестная опция для crypttab?
... systemd-cryptsetup[737]: Encountered unknown /etc/crypttab option 'keyscript=/lib/cryptsetup/scripts/insecure', ignoring.
Только для ударов, я пытался удалить keyscript опцию и использовать файл ключей, и все это просто работало! На самом деле я попробовал другие опции как смещенный файлом ключей, и они работают также. Следовательно, проблема связана где-нибудь с keyscript опцией. У кого-либо есть какая-либо идея почему?
2 ответа
Попробуйте опцию "initramfs" в Вашем/etc/crypttab (согласно https://unix.stackexchange.com/a/447676/356711). Ваш /etc/crypttab был бы затем похож на это:
# UUID is not required here since the path to the LV won't change
secure /dev/vg0/secure none luks,keyscript=/lib/cryptsetup/scripts/insecure,initramfs
Обратите внимание на то, что это могла бы быть проблема, что Ваша корневая фс находится в контейнере LVM. Эта проблема также упоминается в статье, связанной выше: "Но это в настоящее время только работает (надежно), если корневое устройство не находится в LVM". К счастью, кажется, что обходное решение обеспечивается.
Моя система похожа на это:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
└─sda1 8:1 0 931.5G 0 part
└─md1 9:1 0 931.4G 0 raid1
└─md1_crypt 253:3 0 931.4G 0 crypt
└─raid_crypt_vg-data_lv 253:4 0 931.4G 0 lvm /raid
sdb 8:16 0 931.5G 0 disk
└─sdb1 8:17 0 931.5G 0 part
└─md1 9:1 0 931.4G 0 raid1
└─md1_crypt 253:3 0 931.4G 0 crypt
└─raid_crypt_vg-data_lv 253:4 0 931.4G 0 lvm /raid
sdc 8:32 0 465.8G 0 disk
├─sdc1 8:33 0 953M 0 part /boot
└─sdc2 8:34 0 464.8G 0 part
└─sdc2_crypt 253:0 0 464.8G 0 crypt
├─system_crypt_vg-data_lv 253:1 0 447G 0 lvm /
└─system_crypt_vg-swap_lv 253:2 0 17.8G 0 lvm [SWAP]
... и следующее /etc/crypttab делает волшебство дешифрования с keyscript (!) в Ubuntu 18.04.2 LTS:
$ cat /etc/crypttab
# <target name> <source device> <key file> <options>
sdc2_crypt UUID=[...] none luks,discard,keyscript=/etc/decryptkeydevice/decryptkeydevice_keyscript.sh
md1_crypt /dev/md1 none luks,discard,keyscript=/etc/decryptkeydevice/decryptkeydevice_keyscript.sh,initramfs
Обратите внимание что дешифрование sdc2_crypt с обеспеченными работами keyscript без initramfs опции (потому что это содержит корневую фс и таким образом "автоматически" рассматривается в initramfs фазу загрузки). md1_crypt уже был только дешифрован в течение initramfs фазы загрузки (и таким образом с keyscript согласно crypttab записи) после того, как я добавил initramfs опцию. Более позднее дешифрование md1_crypt в течение systemd фазы загрузки не работает с keyscript, данным в crypttab, потому что "systemd cryptsetup" не поддерживает опцию keyscript, см. https://github.com/systemd/systemd/pull/3007.
Вы можете перенести файл в initramfs, изменив каталог "/usr/share/initramfs-tools" . См. «man initramfs-tools»
. Для примера я просто хотел использовать файл «passdev» из «/lib/cryptsetup/scripts» в моем файле keyscript, и поскольку этого файла не было в initramsfs, поэтому я легко отредактировал «/ usr/share/initramfs-tools/hooks/cryptroot» и добавил новую строку («copy_exec /lib/cryptsetup/scripts/passdev»), и теперь все работает. но учтите, что при обновлении linux он может исчезнуть. Так что лучшим решением я считаю написать скрипт для копирования в "/usr/share/initramfs-tools/conf-hooks.d"