Использование одной парольной фразы для разблокировки нескольких зашифрованных дисков при загрузке

23

На моей машине есть SSD, на котором я установил систему, и жесткий диск, который я использую в качестве хранилища для больших и / или редко используемых файлов. Оба зашифрованы, но я решил использовать для них одну и ту же фразу-пароль. SSD монтируется в /и HDD в /usr/hdd(у каждого отдельного пользователя есть каталог и он может символьную ссылку, как им нравится из домашнего каталога).

Когда система загружается, она немедленно запрашивает парольную фразу для SSD, а спустя пару секунд - парольную фразу для жесткого диска (она монтируется автоматически). Учитывая, что обе пароли одинаковы, есть ли способ настроить систему для запроса только один раз?

doublep
источник
Вы могли бы написать expectскрипт или аналогичный файл, который вызывается для монтирования дисков вместо того, чтобы система делала это. Вместо этого система будет вызывать скрипт, который будет запрашивать пароль, сохранять его и предоставлять для каждой из операций монтирования.
h3rrmiller
Если я правильно понимаю вашу идею, она не может быть применена к SSD, так как именно с нее загружается система. Но тогда это становится бессмысленным, так как мне все равно нужно было бы вводить парольную фразу для жесткого диска отдельно. Или нет?
удвоение
Вы можете использовать, /etc/crypttab чтобы разблокировать второй диск .
Джейсонвриан
1
@jasonwryan, если это можно расширить до ответа, тогда ... ответы должны публиковаться как ответы, а не комментарии.
Дероберт,
1
@ derobert иногда у людей нет времени или желания написать хороший ответ.
Джейсонвриан

Ответы:

24

Дистрибутивы на основе Debian:

Debian и Ubuntu поставляют скрипт кэширования паролей decrypt_keyctl с пакетом cryptsetup .

Сценарий decrypt_keyctl предоставляет один и тот же пароль для нескольких зашифрованных целей LUKS, избавляя вас от необходимости вводить его несколько раз. Это может быть включено в crypttab с keyscript=decrypt_keyctlопцией. Один и тот же пароль используется для целей, имеющих одинаковый идентификатор в поле ключевого файла . При загрузке пароль для каждого идентификатора запрашивается один раз.

Пример crypttab :

<target>      <source>         <keyfile>      <options>
part1_crypt   /dev/disk/...    crypt_disks    luks,keyscript=decrypt_keyctl
part2_crypt   /dev/disk/...    crypt_disks    luks,keyscript=decrypt_keyctl

После того, как вы обновили свою криптабу , вам также придется обновить initramfs, чтобы применить изменения. Использование update-initramfs -u.

Полный файл readme для decrypt_keyctl находится в /usr/share/doc/cryptsetup/README.keyctl

К сожалению, в настоящее время это не работает в системах Debian, использующих systemd init, из- за ошибки (другие системы init не должны быть затронуты). В справочной странице Debian crypttab в качестве обходного пути предлагается использовать initramfsопцию принудительной обработки на этапе загрузки initramfs.


Распространения, которые не предоставляют сценарий decrypt_keyctl :

Если decrypt_keyctrl не предоставлен вашим дистрибутивом, устройство можно разблокировать с помощью ключевого файла в зашифрованной корневой файловой системе. Это когда корневая файловая система может быть разблокирована и смонтирована перед любыми другими зашифрованными устройствами.

LUKS поддерживает несколько ключевых слотов. Это позволяет альтернативно разблокировать устройство с помощью пароля, если файл ключа недоступен / потерян.

  1. Сгенерируйте ключ со случайными данными и установите для него права доступа только для чтения владельцу, чтобы избежать его утечки. Обратите внимание, что файл ключа должен находиться в корневом разделе, который сначала разблокируется.

    dd if=/dev/urandom of=<path to key file> bs=1024 count=1
    chmod u=rw,g=,o= <path to key file>
    
  2. Добавьте ключ к вашему устройству LUKS

    cryptsetup luksAddKey <path to encrypted device> <path to key file>
    
  3. Настройте crypttab для использования файла ключа. Первая строка должна быть корневым устройством, так как устройства разблокированы в том же порядке, как указано в crypttab . Используйте абсолютные пути для ключевых файлов.

    <target>      <source>         <keyfile>                  <options>
    root_crypt    /dev/disk/...    none                       luks
    part1_crypt   /dev/disk/...    <path to key file>         luks
    
sebasth
источник
С первых строк readme это выглядит очень многообещающе, спасибо. Я проверю это завтра (не хочу перезагружаться сейчас).
удвоение
К сожалению, это не работает (как без изменений). Смотрите моиcrypttab (я не трогал UUID=созданный системным установщиком, я думаю, это не имеет значения) и полученные записи в/var/log/syslog . Ошибки вроде понятны, но я понятия не имею, что с ними делать. Файл /lib/cryptsetup/scripts/decrypt_keyctlсуществует, поэтому я не знаю, почему он жалуется на неизвестный вариант. Я также понятия не имею, что указать в качестве ключевого файла, я не вижу объяснения нигде ...
дабл
Вы проверяли, что decrypt_keyctl включен в initramfs? Проверьте это, используя опцию verbose при обновлении изображения: update-initramfs -u -k $(uname -r) -vоно должно выводиться Adding binary /lib/cryptsetup/scripts/decrypt_keyctl.
Себастьян
1
Чтобы увидеть, что содержит initramfs:lsinitramfs /boot/initrd.img-$(uname -r)
Себаст
3
Ну, извините, теперь, когда я уделял больше внимания на то , что update-initramfsсказал, я это заметил: E: /usr/share/initramfs-tools/hooks/cryptkeyctl failed with return 1.. После небольшого поиска я обнаружил, что мне, вероятно, нужен keyutilsпакет (на самом деле он не был установлен). Теперь это update-initramfsудается и lsinitramfsупоминает decrypt_keytls. Обновится после следующей загрузки (скорее всего завтра).
удвоиться
3

Вот мой обходной путь к Debian, учитывая ошибку, упомянутую выше @sebasth.

Моя настройка немного отличается. У меня есть зашифрованный корневой раздел и куча raid-дисков. Для меня мне пришлось добавить опцию initramfs в crypttab:

<target>      <source>         <keyfile>      <options>
part1_crypt   /dev/disk/...    crypt_disks    plain,cipher=aes-xts-plain64,keyscript=decrypt_keyctl,initramfs
part2_crypt   /dev/disk/...    crypt_disks    plain,cipher=aes-xts-plain64,keyscript=decrypt_keyctl,initramfs

Это сообщает update-initramfs, что я хочу, чтобы эти записи crypttab были смонтированы в initramfs. Я проверил свою криптабу, запустив

cryptdisks_start part1_crypt
cryptdisks_start part2_crypt

Обратите внимание, что мои raid-диски являются обычными dm-crypt. Это означало, что я не мог использовать метод luks keyfile, который работает вокруг ошибки systemd keyscript. Для простого dm-crypt мне пришлось бы хранить парольную фразу в незашифрованном виде.

Зашифрованные диски должны быть смонтированы перед update-initramfsзапуском; в противном случае это приведет к ошибкам. Мне пришлось искать следующие строки при сборке моих initramfs:

update-initramfs -k -u -v | grep 'keyctl'

который показал следующие два файла:

/bin/keyctl
cryptkeyctl

будучи добавленным в initramfs.

Наконец, мне пришлось отключить systemd, обрабатывающую мою crypttab, чтобы справиться с ошибкой, указанной выше: systemd не поддерживает опцию keyscript в crypttab. Для этого я добавил опцию ядра

GRUB_CMDLINE_LINUX_DEFAULT="quiet luks.crypttab=no"     

в / etc / default / grub и запустил update-grub. systemd теперь игнорирует crypttab, и все зашифрованные разделы загружаются в initramfs.

Поскольку у меня есть зашифрованный корневой раздел, cryptroot не может кэшировать мой ключ. Это означает, что я должен ввести свой пароль дважды; один для корневого раздела и один раз для моего raid-массива.

user128063
источник
1

Другой вариант - использовать /lib/cryptsetup/scripts/decrypt_derivedскрипт, который также является частью cryptsetup в Debian / Ubuntu.

Вместо того, чтобы кэшировать ключ, вы используете ключ громкости одного диска в качестве дополнительного пароля для второго диска. Это требует добавления второго пароля на второй (и третий и т. Д.) Зашифрованный диск, но LUKS это поддерживает. Следовательно, это решение также работает, если ваши зашифрованные диски не используют один и тот же пароль.

Пример добавления ключа из sda6crypt в sda5:

Добавьте ключ громкости sda6crypt в качестве дополнительного пароля для sda5:

mkfifo fifo
/lib/cryptsetup/scripts/decrypt_derived sda6crypt > fifo &
cryptsetup luksAddKey /dev/sda5 fifo
rm fifo

Настройте sda5crypt для автоматической разблокировки в /etc/crypttab

ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab

При этом используется именованный канал ( fifo) для передачи ключа, чтобы избежать необходимости хранить ключ тома во временном файле на диске.

Эта keyscriptопция работает только в том случае, если crypttabона обрабатывается оригинальными инструментами cryptsetup Debian, переопределение systemd в настоящее время не поддерживает ее. Если ваша система использует systemd (который является большинством систем), вам нужна initramfsопция для принудительной обработки в initrd средствами cryptsetup до запуска systemd.

Основано на /unix//a/32551/50793

JanKanis
источник
Должен сказать, что это прекрасное решение Работало сразу, без сбоев на Debian 10 Buster!
Янус