LUKS keyScript игнорируется ... запрашивает пароль

Позвольте мне начать с того, что я не новичок в LUKS. Я много раз настраивал LUKS с помощью скриптов ключей с LVM и без него. Я не уверен, что на самом деле здесь происходит, хотя. У меня есть система, которая имеет один зашифрованный раздел. Мой диск организован следующим образом:

# lsblk

НАИМЕНОВАНИЕ MAJ: MIN RM РАЗМЕР RO ТИП MOUNTPOINT
sda 8:00 128G 0 диск  
S─sda1 8:12 128G 0 часть  
  V─vg0-корень 253: 1 0 20G 0 лвм /
  V─vg0-secure 253: 6 0 100M 0 lvm   
  │ └─secure 253: 7 0 98M 0 crypt / root / secure
  V─vg0-swap 253: 4 0 1G 0 lvm [SWAP]

Мой /etc/crypttabфайл выглядит примерно так

# UUID здесь не требуется, так как путь к LV не изменится
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 и установки своего файла с ключами.

Насколько я могу судить, мой файл сценария даже не копируется в файл initrd.img. Теперь, когда я думаю об этом, я не думаю, что он будет скопирован в файл initrd.img, поскольку корневой раздел не зашифрован, и файл сценария должен быть легко доступен оттуда.

После перезагрузки система видит запись из crypttab и запрашивает пароль (который в моем случае фактически не существует, потому что единственный ключ - это файл ключей, заполненный случайными битами), вместо использования ключа для разблокировки раздела LUKS. Я попытался вынуть LUKS из LVM и положить его на sda2, и результаты были такими же. Я также знаю, что скрипт работает, потому что cryptsetup luksOpen /dev/vg0/secure secure -d - <<< "$(/lib/cryptsetup/scripts/insecure)"работает как брелок и расшифровывает мой раздел LUKS.

Я пробовал это в Ubuntu 16.04.2 и Ubuntu Mate 16.04.2 с теми же результатами. Я использовал ключи от скриптов раньше без каких-либо проблем. Единственное отличие заключалось в том, что в прошлом мой раздел всегда был зашифрован. Если кто-то может пролить свет, я был бы признателен. Мне нужен только очень маленький зашифрованный раздел, потому что я планирую клонировать эту систему, и я не хочу клонировать его с зашифрованным целым разделом.

ОБНОВЛЕНИЕ 2017-04-26

При рытье логов я нашел строку со следующей ошибкой, которая не имеет смысла. С каких это пор «keyscript = / path / to / script» является неизвестной опцией для crypttab?

... systemd-cryptsetup [737]: обнаружена неизвестная опция / etc / crypttab 'keyscript = / lib / cryptsetup / scripts / insecure', игнорируется.

Просто для удовольствия, я попытался удалить опцию keycript и использовать ключевой файл, и все это просто сработало! На самом деле, я пробовал другие варианты, такие как keyfile-offset, и они тоже работают. Следовательно, проблема лежит где-то с опцией keyscript. У кого-нибудь есть идеи почему?

Попробуйте опцию "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выполняет магию дешифрования с помощью клавиш (!) в 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с помощью предоставленного скрипта ключей работает без опции initramfs (потому что он содержит корень fs и, таким образом, «автоматически» рассматривается на этапе загрузки initramfs). md1_cryptбыл расшифрован только во время фазы загрузки initramfs (и, следовательно, с помощью скрипта ключа в соответствии с записью crypttab) после того, как я добавил опцию initramfs. Более поздняя расшифровка md1_crypt во время фазы загрузки systemd не работает со сценарием ключей, заданным в crypttab, поскольку «systemd cryptsetup» не поддерживает параметр keyscript, см. Https://github.com/systemd/systemd/pull/3007 .