Luks, usbkey, fallback to passphrase

Есть там одна неописанная штука в этом passdev - таймаут. Появилась в виде патча когда-то, но в документации про нее нет ничего - только в исходном коде можно понять, что есть. Вот если эту опцию добавить (вот надо выяснить, как это сделать - я еще не допер, как скрипту таймаут передать), то по истечению таймаута из скрипта passdev вываливается с неудачей, а вот что дальше будет происходить - вопрос. Если в слотах LUKS у тебя есть также и пароль, то вполне вероятно, что он перейдет как раз к вводу пароля.

Вот патч: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502598#10 и он уже приложен в Debian, ничего самому делать не надо. Напиши, кстати, автору. Может, прояснит. Он русскоязычный.

Таймаут в секундах. И еще надо в crypttab передать число попыток tries=1 (man crypttab) в ту же строчку, где и passdev. Это также и рекомендация автора патча.

Если в слотах LUKS у тебя есть также и пароль, то вполне вероятно, что он перейдет как раз к вводу пароля.

Хотя я полагаю, что так не произойдет. Просто корень не обнаружит, скажет об этом, но и флешку больше ждать не будет. Надо уточнить в документации cryptsetup, что он делает, когда keyscript обломился. Я вот глянул man crypttab, но там что-то не написано.

keyscript=<path>
           The executable at the indicated path is executed with the key file
           from the third field of the crypttab as its only argument and the
           output is used as the key. This also works with encrypted root
           filesystems via initramfs if the executable is self-contained (i.e.
           an executable which does not rely on any external program which is
           not present in the initramfs environment).

           LIMITATIONS: All binaries and files on which the keyscript depends
           must be available at the time of execution. Special care needs to
           be taken for encrypted filesystems like /usr or /var. As an
           example, unlocking encrypted /usr must not depend on binaries from
           /usr/(s)bin.

           All fields of the appropriate crypttab entry are available to the
           keyscript as exported environment variables:

           CRYPTTAB_NAME
               The target name

           CRYPTTAB_SOURCE
               The source device

           CRYPTTAB_KEY
               The key file

           CRYPTTAB_TRIED
               Number of previous tries since start of cryptdisks (counts
               until maximum number of tries is reached).

           CRYPTTAB_OPTIONS
               A list of exported crypttab options

           CRYPTTAB_OPTION_<option>
               The value of the appropriate crypttab option, with value set to
               'yes' in case the option is merely a flag.

Надо уточнить в документации cryptsetup, что он делает, когда keyscript обломился.

Полагаю, что это будет равнозначно тому, что keyfile не найден, то есть поведение будет таким же, как и в случае, если у тебя есть шифрованный раздел, у которого есть одновременно в слотах открывашка по key file и по паролю. Ты пытаешься открыть по keyfile, которого нет, cryptsetup обламывается, и вот дальше он либо выпадает вообще, либо предлагает еще пароль ввести как вторую возможность. Это и надо проверить. Просто мне вот прямо сейчас проверить не на чем и возиться не хочется. Я забыл, что там происходит. В сетапе, который я делал, passdev просто тупо ждет без конца.

А, смотри: если почитать то, с чего началось там обсуждение, то автор патча такую же ситуацию описывает, как тебе надо. Значит, все должно работать так, как ты хочешь. И, кстати, он говорит про Ctrl-C. Можно нажать и ты выскочишь в пароль:

Today I discovered in README.initramfs.gz that there is a new keyscript, passdev. It seems to be a really nice idea, but I think it misses an important option, a timeout.

Currently I have an unencrypted / and LUKS-crypted /home and swap, the keyfile for the later two is saved on an USB-stick. When I forget the USB-stick, I would like to still be able to boot the box and enter a passphrase by hand (luksOpen). This is not possible with passdev at the moment (I could ^C it, but that's not userfriendly).

Could you implement a timout option?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502598#5

Привет, Zubok!

Today I discovered in README.initramfs.gz that there is a new keyscript, passdev. It seems to be a really nice idea, but I think it misses an important option, a timeout.

Сейчас там есть описание этой опции (версия README.initramfs.gz из пакета cryptsetup 2:1.6.6-5), вот выдержка:

The «key» part of /etc/crypttab will be interpreted as <device>:<path>[:<timeout>]
....
The timeout option has to be in seconds.

Сейчас доступа к компьютеру, на котором я пытался настроить такую конфигурацию, под руками нет, смогу добраться до него только через несколько дней. Насколько я помню, ситуация следующая:

- сценарий № 1: указываем timeout. Результат: бесконечный цикл поиска флэшки с ключём. По окончании timeout'a, начинается новая попытка найти ключевой файл. Запроса на ввод пароля не происходит.

- сценарий № 2: указываем timeout и указываем tries=1 (например). Результат: по окончании timeout'a, больше не производится попыток поиска ключевого файла на флэшке, но и пароль не запрашивается. Компьютер «подвисает» на несколько минут, после чего запускается аварийный shell initramfs'a.

Сейчас я настроил компьютер по сценарию № 2. Если флэшка не вставлена, то через несколько минут запускается shell initramfs'a, из которого я ручками делаю:

cryptsetup luksOpen ...
lvm vgscan
lvm vgchange -ay

У меня сложилось впечатление, что правильной реализацией была бы возможность указания нескольких keyscript'ов (для их последовательного перебора), и возникла мысль, что возможно, это и было реализовано - но информации об этом я не нашел (хотя искал плохо).

Спасибо за ссылки, посмотрю.

И вообще, спасибо.

Немного не в тему. Наткнулся на дельный совет:

I now believe that using the UUID is a risk when your USB disk breaks there’s no way to recover. by-label looks saner.

И, кстати, он говорит про Ctrl-C. Можно нажать и ты выскочишь в пароль

Надо будет попробовать.

Просмотрел changelog (1.6.6 > 1.7.3), поискал по wiki и issues у cryptsetup'a. Ничего по теме не нашел. Похоже, нужного функционала там нет - если, конечно, CTRL+C не сработает :)

Немного не в тему. Наткнулся на дельный совет:

I now believe that using the UUID is a risk when your USB disk breaks there’s no way to recover. by-label looks saner.

Я так и делал: расшифровака root раздела ключом (комментарий)

И, кстати, он говорит про Ctrl-C. Можно нажать и ты выскочишь в пароль

Надо будет попробовать.

А будет то же самое, я полагаю - вывалится в шелл. Есть одно отличие твоего сценария: он шифрует не корень, а /home. Об этом он пишет. Но я не вижу разницы. В твоем случае просто все, что нужно, засовывается при помощи initramfs. Но раз он утверждает, что у него что-то такое получалось, то, значит, он как-то сумел заставить систему спросить пароль. Что-то магическое он сказал.

У меня сложилось впечатление, что правильной реализацией была бы возможность указания нескольких keyscript'ов (для их последовательного перебора)

Я тоже смотрел опции и тоже не нашел быстро ничего, но зародилась идея, которая в man crypttab [1] явно не описана. А что если два раза в crypttab указать корень, но в одной строчке (первой) — по keyfile, а вторая строчка — по паролю? Тогда, может, cryptsetup пройдет все строчки последовательно, пока они не кончатся?

[1]

       Each
       filesystem is described on a separate line; fields on each line are
       separated by tabs or spaces. Lines starting with “#” are comments,
       empty lines are ignored. The order of records in crypttab is important
       because the init scripts sequentially iterate through crypttab doing
       their thing.

Но раз он утверждает, что у него что-то такое получалось, то, значит, он как-то сумел заставить систему спросить пароль.

Хотя и не факт. Вот эти его слова ниже немного туманны. То, что он в скобках написал luksOpen может намекать на то, что он делает то же, что и ты — в консоли вручную открывает шифрованный раздел после выхода из ожидания флешки. То есть у него тоже может *автоматом* пароль не предлагаться.

I would like to still be able to boot the box and enter a passphrase by hand (luksOpen)