LINUX.ORG.RU

Timed out waiting for device... при установке ключа LUKS на флешку

 , , ,


0

2

Привет, решил разобраться с шифрованием в линукс.
Вроде все нормально было, пока не создал для LUKS ключ на флешке. ситуация такая
debian jessie
шифрование задавалось при установке системы
на флешке лежит /boot с GRUB'ом и ключ
на харде LUKS+LVM
пока вместо ключа был пароль, все было нормально, но когда был создан ключ, при загрузке появилась 1,5минутная задержка

[ ** ] A start job is running for dev-disk-by\x2uuid-eee42...1s / 1min 30s

[ TIME ] Timed out waiting for device dev-disk-by\x2uuid-eee...keyfile.device
[DEPEND] Dependency failed for Cryptography Setup for sda1_crypt.
[DEPEND] Dependency failed for Encrypted Volumes.

sda1_crypt - это хард
а вот uuid-eee42... - это флешка с ключом
а dev-disk-by\x2uuid-eee...keyfile, это путь к ключу

но расшифровка происходит и система работает, помогите пожалуйста разобраться в причине данной ошибки

crypttab:

sda1_crypt UUID=(...) /dev/disk/by-uuid/(id флешки):/keyfile luks,keyscript=/lib/cryptsetup/scripts/passdev

Очевидно, что стартовые скрипты ожидать пока будет подключено устройство с ключом шифрования.

kostik87 ★★★★★ ()
Ответ на: комментарий от kostik87

но флешка то подключена изначально, на ней находится grub и /boot
данное сообщение появляется уже после того как был дешифрован корневой раздел

M_Corvinus ()
Ответ на: комментарий от kostik87

тут дело не в usb, я когда начал разбираться с проблемой на виртуалке, попробовал сделать вместо флешки второй жесткий диск на пару гиг, и закинул на него /boot, grub и ключ, проблема осталась. Что на основной системе с флешкой, что на виртуальной с флешкой или дополнительным hdd, проблема одинакова, все грузится и работает, но задержка не уходит

M_Corvinus ()

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862

Один из многоуважаемых авторов systemd решил что половина случаев использования crypttab не нужна и выпилил опцию scriptdev.

Можно просто заставить systemd забыть про существование этого юнита, т.к. монтирование один хрен происходит из шелл-скрипта в initrd

maloi ★★★★★ ()

Увы

/usr/share/doc/cryptsetup/README.initramfs.gz:

10. The «passdev» keyscript

If you have a keyfile on a removable device (e.g. a USB-key), you can use the passdev keyscript. It will wait for the device to appear, mount it read-only, read the key and then unmount the device.

The «key» part of /etc/crypttab will be interpreted as <device>:<path>[:<timeout>], it is strongly recommended that you use one of the persistent device names from /dev/disk/*, e.g. /dev/disk/by-label/myusbkey.

This is an example of a suitable line in cryptsetup: cryptroot /dev/hda2 /dev/disk/by-label/myusbkey:/keys/root.key cipher=aes-cbc-essiv:sha256,size=256,hash=plain,keyscript=/lib/cryptsetup/scripts/passdev

The above line would cause the boot to pause until /dev/disk/by-label/myusbkey appears in the fs, then mount that device and use the file /keys/root.key on the device as the key (without any hashing) as the key for the fs.

The timeout option has to be in seconds.

If any modules are required in order to mount the filesystem on the removable device, then initramfs-tools needs to be configured to add these modules to the initramfs. This can be done by listing the required modules in /etc/initramfs-tools/modules.

Указание ключевого файла в виде /dev/устройство:/путь/к/файлу требует keyscript=passdev, но release notes:

There are some cryptsetup features that are unfortunately not supported when running with systemd as the init system. These are:

<...>

  • keyscript

If your system relies on any of these for successful booting, you will have to use sysvinit (sysvinit-core) as init system. Please refer to Section 5.6, “Upgrading installs the new default init system for Jessie” for how to avoid a particular init system.

Добавляйте флешку в fstab и указывайте путь к ключевому файлу от точки её монтирования.

anonymous ()
Ответ на: комментарий от maloi

Спасибо за ссылку. Сейчас на работе, вечером почитаю, посмотрим что получится

anonymous ()
Ответ на: комментарий от anonymous

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

M_Corvinus

anonymous ()
Ответ на: комментарий от anonymous

кстати, можно фанатов системд позвать intelfx, узнать как они отмажутся по этому поводу

maloi ★★★★★ ()
Ответ на: комментарий от anonymous

я в свое время сделал примерно так

systemctl mask systemd-cryptsetup@sda1_crypt.service

maloi ★★★★★ ()
Ответ на: комментарий от maloi

Чего тебе надобно?

У тебя там 4.2 выше. «Не впиливал» != «выпилил».

intelfx ★★★★★ ()
Ответ на: Увы от anonymous

проверил указание пути через точку монтирования
если убрать keyscript, все равно ругается

cryptsetup: WARNING: target sda1_crypt uses a key file, skipped

буду копать дальше

M_Corvinus ()
Ответ на: комментарий от maloi
systemctl mask systemd-cryptsetup@sda1_crypt.service

проблему решил, но как это повлияет на работу шифрования? можно поподробнее про блокировку systemd-cryptsetup@.service?

M_Corvinus ()
Ответ на: комментарий от M_Corvinus

до тех пор пока в initrd существует скрипт, который умеет корректно читать crypttab - все будет работать, как только этот скрипт выпилят - нужно будет придумывать что-то новое, можно например написать свой systemd-cryptsetup@.service, который будет вызывать cryptdisks_{start,stop}

maloi ★★★★★ ()
Ответ на: комментарий от maloi

спасибо за помощь, надо будет поглубже разобраться с тем как все работает на данный момент, чтобы заранее подготовится к будущим приколам

M_Corvinus ()
Ответ на: комментарий от intelfx

Ну какбы уже давно существует описание формата crypttab(5), в котором описана работа keyscript
Ребята из systemd решили, что этот crypttab - неправильный и написали свой, без keyscript, precheck, check, с переименованием некоторых других опций и добавлением systemd-специфичных опций.

Написать свой, альтернативный crypttab - это и есть выпилить из оригинального ненужные опции.

maloi ★★★★★ ()
Ответ на: комментарий от maloi

давно существует описание формата crypttab(5), в котором описана работа keyscript

http://linux.die.net/man/5/crypttab — не вижу. «Ребята из systemd» не обязаны имплементить дебианоспецифичные расширения. Это задача мейнтейнеров systemd в Debian.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

учитывая, что «The /etc/crypttab file format is based on the Debian cryptsetup package» - «дебианоспецифичные расширения» - это и есть нормальный формат cryptesetup, а все остальное - дистрибутивоспецифичные расширения.

maloi ★★★★★ ()
Ответ на: комментарий от maloi

Нет, конечно. «Based on» — это именно «based on». От того, что в одном дистрибутиве что-то сделали, остальные дистрибутивы/проекты не становятся внезапно обязанными делать то же самое.

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

вообще если уж на то пошло, то мейнтейнеры systemd в Debian предлагали апстриму изменения, которые исправили бы этот недостаток, но аргументация апстрима в лице ЛП была удивительно хороша - вы не используете dbus, поэтому патчи я принимать не буду.

maloi ★★★★★ ()
Ответ на: комментарий от maloi

мейнтейнеры systemd в Debian предлагали апстриму изменения

вы не используете dbus, поэтому патчи я принимать не буду.

Где?

intelfx ★★★★★ ()
Ответ на: комментарий от maloi

Не нашёл.

Леннарт предлагает вместо того, чтобы добавлять в systemd'шную инфраструктуру ask-password поддержку нетекстовых парольных фраз, воспользоваться сразу kernel keyring. И, чтобы два раза не ходить, взаимодействие между агентами было предложено перепилить с сокетов и inotify на kdbus.

И как бы он имеет полное право просить, чтобы в апстрим входили только «идейно» правильные решения. Почему мейнтейнеры не согласились применить патч (который вроде как даже был написан) локально — спрашивать нужно у них.

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

взаимодействие между агентами было предложено перепилить с сокетов и inotify на kdbus.

Вот же они, положила.

Почему мейнтейнеры не согласились применить патч локально

Если мне не изменяет память одним из достоинств убийцы sysvinit провозглашалась унификация между дистрибутивами. Если пойти по тому пути что ты предлагаешь через 5 лет у каждого дистрибутива будет свой несовместимый с остальными systemd, а через 10 администратор RHEL должен будет день разбираться чтобы понять как настроить включение сервиса в Gentoo.

maloi ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.