LUKS-скрипт ігнорується ... запитує пароль


10

Почніть з того, що я не новачок у ЛЮКС. Я багато разів встановлював LUKS за допомогою сценаріїв клавіш із та без LVM. Я не впевнений, що насправді тут відбувається. У мене є система, яка має єдиний зашифрований розділ. Мій привід організований так:

# lsblk

ІМЕЙ МАЙ: МІН RM РОЗМІР РОЗВИТОК ТИПУ RO
sda 8: 0 0 128G 0 диск  
└─sda1 8: 1 0 128G 0 частина  
  ├─vg0-root 253: 1 0 20G 0 lvm /
  ├─vg0-безпечний 253: 6 0 100M 0 lvm   
  │ └─безпечно 253: 7 0 98M 0 склеп / корінь / захищено
  └─vg0-swap 253: 4 0 1G 0 lvm [SWAP]

Мій /etc/crypttabфайл виглядає приблизно так

# UUID тут не потрібно, оскільки шлях до НН не зміниться
secure / dev / vg0 / secure none luks, keyscript = / lib / cryptsetup / script / небезпечно

Мій /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кілька разів запускався після конфігурації криптовалюти та встановлення файлу клавіш на місце.

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

Після перезавантаження система бачить запис із криптовалюти і запитує пароль (який у моєму випадку насправді не існує, тому що єдиним ключем є файл ключових файлів, наповнений випадковими бітами), а не використання сценарію клавіш для розблокування розділу 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 = / шлях / до / скрипту' невідомий варіант для crypttab?

... systemd-cryptsetup [737]: Зустрічався невідомий / etc / crypttab параметр 'keyscript = / lib / cryptsetup / скрипти / незахищений', ігнорування.

Тільки для ударів, я спробував видалити параметр keycript і скористатися файлом ключів, і все це просто спрацювало! Насправді я спробував інші варіанти, такі як зсув ключів, і вони теж працюють. Отже, проблема полягає десь у варіанті клавіатури. Хтось має ідею, чому?


3
Я думаю, що systemd - це ваша проблема. Швидкий google для systemd та keycript показує помилку та запит на тягу для впровадження keycript у systemd тут . Існує навіть рішення, яке можна отримати з першого посилання.
sergtech

Це було моєю підозрою, а також я продовжував вивчати свою проблему та шукати результати, знайдені в Інтернеті. Я спробував деякі рекомендації тут , але я не впевнений , як отримати файл сценарію в INITRD.
b_laoshi

Відповіді:


3

Спробуйте параметр "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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.