Маскировка ввода пароля в cryptsetup

Зарегтесь на сайте и создайте вики-страничку под этот документ, пусть для начала даже с черновыми и нерекомендуемыми к практическому использованию вариантами. Будет проще её исправлять по мере коментирования, возвращаться с новыми идеями, чем терять разрозненные посты в форуме.

Для вики-странички желательна хоть какая-то завершаемость, а для этого нужен хотя бы прототип инструкции. Инструкции нет. Тест пока что опирался на самодельный загрузчик — это плохо, но это просто эксперименты, нужные, чтобы достичь понимания принципов (cистему всегда надо строить от простого к сложному). В итоговом тексте 80% того поста было бы попросту ненужным информационным мусором. Наконец, у меня столько сырых недоведённых до ума страниц и идей, что я уже не рискую, не видя почти готового варианта, серьёзно браться за что-то новое.

Только без --use-random — оно к plain mode неприменимо (что вполне логично).

Кощеева смерть

Самостоятельно попроходил квест. Инсталлятор Debian'а понятен почти всюду, но в двух местах пришлось тыкать на угад. Первое уже забыл (что-то с разбиениями и конфигурацией дисков), а второе — conversion (uuid'ов?) перед самым finish install в районе записи загрузчика (взял lilo) на внешний носитель.

Извратился и сделал такую схему:
Больше это для теста автоматики. Загручику lilo плохеет, он вываливается в командную строку, но если там всё пдключить, то через некоторое время он-таки добирается до нужных разделов и ОС запускается(!). Есть впечатление, что на одни и те же крипторазделы LUKS он запрашивает пароль по-нескольку раз, ибо тупой, причём на тот момент они уже подключены. Вроде даже если жать Enter вместо ввода пароля, то всё правильно отработает.

В Wheezy версия ядра 3.2. Надо хотя бы 3.5. Такого выбора нет, но есть jessie-β-2, там аж 3.16. Установка проходит штатно, но поддержка графики так и недостестировалась: после apt-get update и apt-get upgrade ядро так обновилось, что больше ОС не загрузилась. При старте системы на ранних стадиях загрузки ядро стабильно падает в панику, и ничего не помогает. Видимо, от идеи выполнять apt-get upgrade придётся отказаться на свой страх и риск до выхода 8.0. :-(

systemd выпиливался указанием опции к загрузчику инсталлятора, но насколько этот метод был успешным, судить не берусь. sysvinit вроде установился.

В jessie новый cryptsetup, там теперь можно так монтировать:вместо старого(этот вариант тоже пока поддерживается, но считается устаревшим).

Разбиение на диски и крипторазделы там всегда было отвратным. Там есть возможность выйти в консоль и сделать всё вручную, но раз в несколько лет плевался и как-то методом тыка добивался нужного от обычного инсталлятора.

Кстати, LILO может плохо понимать навороты с томами, он для минимализма в духе старых систем, безо всяких (крипто)томов. Конечно, всё решает рамдиск, но в него из grub.conf передаются какие-то UID'ы.

Оно нормальное, но недокументированное, до всего надо доходить самому, даже если понимаешь, как это всё внутри должно быть устроено. Общая схема такая: идёшь по пунктам:
И др. Сначала надо выбрать их и указать, как будем их использовать (LVM, LUKS или ещё что). Если выбран LUKS или LVM, то надо вернуться в верх окна и выбрать «сконфигурировать», чтобы он собственно создал новые логические тома или LUKS-устройства, запросил пассфразы и т.д., только после этого новые устройства появятся в списке наряду с
и можно будет аналогичным образом разбираться с ними (новыми устройствами). Ещё нельзя в aes-xts-plain64 задать ключ 512. Эта тема ранее немного обсуждалась, см. 7 пунктов.


Не уверен. Но если вы правы, то, по моим представляениям, это надо сделать до захода в меню detect disks. В частности, этим макаром добиваются того, что инсталлятор увидит /dev/mapper/NAME, который самый внешний и бессигнатурный, позволив уже его разбивать через LVM/LUKS и т.д.

Мне кажется, что он может не захотить распознавать ранее созданные LVM-тома в консоли.

Ещё заметка про софт: в конфигурирование пакетного менеджера зайти стоит, а в install software — нет, т.к. там даже если не выбирать ничего, он наставит всякого дерьма всё равно. Он говорит, что есть base system на CD, а ещё можно поставить «более полную» base system с сети. Так вот, более полную, похоже — это уловка, не надо поддаваться, т.к. там много сомнительного.

Можно попробовать с grub'ом сдеать. Он grub-1 не предлагает уже? В любом случае, тут важно одно: лишь бы работало. Загрузчик всё равно будет кастомный так или иначе, поскольку загрузку гипервизора ни один стандартный LiveCD не умеет. Следовательно, лучше не вытягивать самого себя за волосы из болота подстроек под типичный загрузчик, а подходить, как уже было предложено: нейтральным LiveCD/LiveUSB записывается загрузчик на носитель разово на одну загрузку; потом после загрузки загрузочный носитель затирается (см. пункты 5-8).

P.S. Кстати, миграция через mount union [п. 6] ненужна: initrd/initramfs достаточно умный (комнадная строка загрузчика), там все необходимые тулзы есть. Достаточно будет оттуда вручную подцепить блочное устройство, состоящее из скрытого места на диске, через dmsetup с его БД, и дальше загрузка пойдёт штатным образом.

Во время инсталляции base system инсталлятор предлагает на выбор 2 ядра: linux-image-3.16-2-amd64 и linux-image-amd64. Чем они отличаются? Судя по логам, как я понял, при выборе второго пакет для первого тоже ставится.


Когда нужно сделать некоторое созданное блочное устройство LUKS-контейнером, вы выбираете его в общем списке и говорите use as physical volume for encryption. Он при этом спросит, как его шифровать и всё такое. После выхода из меню блочное устройство будет помечено справа в списке как not active. После этого нужно вверху окна выбрать configure encrypted volumes (ну, чтобы оно запросило пассфразу и сделало его active, после чего данное блочное устройство можно сувать дальше: сделать на нём ФС, разметить под LVM или ещё что). Однако, когда вы заходите в configure encrypted volumes, он вам предлагает на выбор два варианта: create encrypted volumes и finish. В чём логика? Казалось бы, да, вы хотите его создать, но не столько создать, сколько активировать уже созданный. Это путает. Короче, надо выбирать finish (абсолютно нелогично), и тогда на следующем шаге он запрашивает пассфразу для not active устройства. После оно будет помечено как active.

Если же выбрать create encrypted volumes, он запрашивает, какое из доступных блочных устройств шифровать. Можно снова выбрать то, которое not active в основном списке, но что будет дальше, я не пробовал.

Ещё одна нелогичность: после того, как загрузили компоненты с CD посредством соответствующего пункта меню и выбрали, что загружать, cryptsetup уже должен появиться в консоли. Однако, это не так. Надо ещё включить сеть и сконфигурировать её. Настройка сети ничего с сети не загружает, но после этого cryptsetup в консоли появляется, и туда можно лезть выполнять ручную работу. В чём логика, и что это за фазы Луны, я так и не понял.

---

Ставлю ОС в конфигурации как тут, на последней стадии возникают какие-то неисправимые траблы с установкой загрузчика на внешний носитель. Приходится всё прерывать и делать инсталляцию снова, а это опять ждать, пока установится base system (минут 15-20 занимает) и опять кучу ручной работы делать. Но ладно, я терпелив, проходим квест снова. Всё устанавливается, всё грузится, корневую ФС загрузчик не находит и, как положено, вываливается в шелл initramfs. Всё бы ничего, но cryptsetup'а там нет. Думаю, дай поставлю шифрованный своп, хотя не хотел — вроде по вышеприведённой инструкции это в обяз должно добавить туда cryptsetup. Заново всё делать не хочется, поэтому, казалось бы, достаточно загрузиться, всё подмонтировать, а потом выполнить только установку загрузчика. Но это тоже не так. Если install base system не выполняется, инсталлятор не видит носителя с /boot (а потому выбор grub-пункта в меню инсталлятора возвращает ошибку). Если зайти в консоль и сделать chroot /target, то видно, что никаких /dev/sdX-устройств там нет и в помине.

Что ж, значит снова делаем всю инсталляцию с начала и до конца. Сделали. Не грузится. Вообще никак. Чёрный экран, даже меню граба не вылазит. Руками при этом носитель монтируется, /boot там, всё ОК. Скопировал через dd на другой носитель, пробую. С него тоже не грузится. Блин, значит, надо сделать как-то grub-install снова, но как? Можно так же пройти заново всю инсталляцию, а загрузчик так и не начнёт работать, можно ли схитрить и сделать быстрее? ОК, похоже, можно сделать grub-install из-под другой системы.

Грузимся, но там новая засада: нам же надо сделать grub-install для новой системы с новым ядром и не в конвенциональное место записать /boot, да не испохабить ничего на последней работающей системе. Вроде это делается через chroot. Отлично, но после chroot /target ни одно из /dev/sdX устройств не видно. Как тогда он сделает update-grub? Надо бы ему объяснить... Опять лезем в гугл и находим инструкцию/скрипты с mount --bind, которые в чрут пробрасывают деревья /proc, /sys, /dev и т.п.

Сделали, grub-install выполнился. Грузимся снова, проверяем: о, чудо! Оно работает! Попадаем в initramfs-шелл, сейчас, думаю, наконец-то всё подключу, но... да ты ж ё*й ты н*уй!!! Нет там cryptsetup'а. Я уже в полном расстройстве. Как это так?!

Ладно, можно поискать, как принудительно заставить в initramfs включить cryptsetup. Поиск пестрит рецептами, один другого страшнее, от которых хочется выть: нечитаемые скрипты на много листингов и прочая машинерия. Наконец, находится (конечно же, не на официальной странице, где оно должно быть, а у кого-то любителя в заметке):

I have therefore modified cryptsetup initramfs hooks to only include cryptsetup in the initramfs when necessary. I have tested multiple combinations (конечно же, такие вещи не стоит документировать — пусть все выясняют правду методом проб и ошибок) and here is a small summary:

No cryptsetup in initramfs, when:

• no encrypted devices present
• non-rootfs filesystems are encrypted (e.g. /var/lib is encrypted)
• swap is encrypted with random key file (i.e. non-persistent encrypted swap)

cryptsetup is in initramfs, when:

• rootfs is encrypted ( '/' )
• swap is encrypted with a passphrase / key-file (i.e. can unlock & resume from hibernate)
• CRYPTSETUP='y' option is specified in /etc/initramfs-tools/initramfs.conf

The last provision is for the case where one wants to generate an initrd on this machine, which will then be transferred to boot something else.

Чудесно, просто опупеть, как чудесно. Не трудно видеть, что в этой конфигурации, по такой логике, cryptsetup в initramfs ну вообще не нужен! Кто же такой умный? А там и пояснение в конце:Как видим, в 2013-ом году у одного гада зачесались лапки и он-таки полез туда, куда его совсем не просили. Интересно, Dmitrijs Ledkovs готов бы был мне оплатить потеряный день времени?

Судя по гуглу, grub-update/install не пересоздают initramfs, для этого надо то ли dpkg-reconfigure linux-image-... сделать, то ли update-initramfs -u -v перед собственно grub-install. Кстати, вместо извращений с распаковкой initrd для проверки, есть удобная тулза lsinitramfs. Можно пробовать. Я только одно не понял: почему в случае с lilo так нужный cryptsetup всё-таки попал в initramfs.

Продолжение следует.

Да, правы. Во всяком случае, меню инсталлятора всё показывает, хотя LVM- и LUKS-разделы были созданы ранее вручную. Правда, до конца не ясно, скажется ли это на чём-то, когда он захочет сгенерить initramfs [т.е. всё равно ли инсталлятору, как создавались разделы/устройства (в консоли или через меню) или нет, обращает ли он на это внимание при генерации содержимого /boot?].

Нет, всё не так. Собственно, эта страница по ссылке и есть данного автора — он только задекларировал имеющийся статус-кво, а вот кто его таким сделал — этот вопрос остаётся открытым.

Не помогает, как ни извращайся: ни 'y', ни y, ни Y. Пришлось похачить систему, явно её обманывая — указать, что своп шифруется якобы LUKS'ом, да ещё и статическим ключом: в /etc/crypttab вместо имеющегося

root_Volume_Group-system_swap_crypt /dev/mapper/root_Volume_Group-system_swap /dev/urandom cipher=aes-xts-plain64,size=256,swap

прописывается

root_Volume_Group-system_swap_crypt /dev/mapper/root_Volume_Group-system_swap none luks

После этого надо подключить этот «swap», чтобы в /dev/mapper появилось устройство — initramfs при создании лезет туда и проверяет, какие у него параметры и что (какие криптомодули) нужно положить к себе в initramfs.

Ещё бесит номенклатура: такое впечатление, что у загрузчика есть конечная глубина проверок, и имена конструируются в виде VolumeGroup-LogicalVolume_crypt, хотя можно адресовать напрямую (такое имя — симлинк). Соответственно, когда уровней вложенности много (LUKS в LVM в другом LUKS ещё в одном LVM), все эти чёрточки и подчёркивания перестают однозначно указывать на то, где искать нужное устройство, и из-за этого лезут глюки. Может быть, я всё неправильно понял, но впечатления таковы.

Короче, после этого всё взлетает и грузится, хотя сделано грязно, надо как-то иначе. Перед тем, как выпасть в шелл, initramfs очень долго шарится по дискам и опрашивает их, пытаясь найти устройство для root-ФС. Интересно, можно ли его проинструктировать не заниматься этим?


Теперь всё прошло нормально, даже Xen установился и гипревизор грузится, dom-0 работает.

С графикой что-то странное. xdm стартует прекрасно, но только на одном дисплее. Запустить два xdm'а не получается никак: если Xservers отредактировать, добавив ещё одну строку, не запускается ни один (хорошо, что хоть система при этом намертво не завешивается). Однако, если запускаем один xdm, он легко запускается на любом дисплее.

Тем не менее, несмотря на такие глюки, вручную через xinit с текстовой консоли дополнительные X-сервера на других дисплеях запускаются без проблем. Интересно, можно ли xdm так же принудительно запустить с консоли на других дисплеях? Как ни экспериментировал, не получилось. В старых ОС на точно таких же конфигах всё работает наура.


systemd тоже. ☺ Можно, наверно, его удалить, в других ссылках были инструкции на эту тему (смена загрузки с systemd на System V). Какая загрузка используется по умолчанию — непонятно. /etc/init.d/xdm start работает, /etc/rc?.d/ в системе тоже присутствуют.

Вспомнил, что на старой системе на таком же железе было так: с Xen'ом не запускалось никак, а без него запускалось только с nomodeset, передаваемом ядру. Думаю, дай проверю, как теперь тут, на новом ядре. Итоги: с nomodeset графика с Xen вообще не запускается; без Xen запускается, но больше одного xdm'а по-прежнему не запустить, и принудительный старт графики на иных дисплеях через xinit продолжает работать.


Можно, хак найден: дописать rootdelay=0 к опциям загрузки. Он тогда практически моментально выбрасывается в шелл, что нам и нужно (всё равно автоматикой там ничего толком не цепляется).


Хак грязный, хотелось бы почистить.

Для начала поэкспериментировал с указанием опции загрузчику на лету. Так, чтобы после указания всё начинало цепляться автоматически, не происходит. Однако, самый верхний уровень шифрования действительно можно сделать автоматикой — для этого дописываемк опциям загрузки ядра. Там же можно указать через ещё одну запятуюили lvm=1, но это ни на что уже не сказывается. После указания такого cryptopts он подключает самый внешний бессигнатурный слой шифрования, создавая устройство /dev/mapper/cryptroot, но догадаться запросить LUKS-пароль уже на сам /dev/mapper/cryptroot не может. В общем-то, в командной строке с автодополнением набирать команды намного проще, чем в grub2-меню в загрузчике, так что лучше cryptopts ядру (т.е. на лету) не указывать вообще никакой.

Это всё меня натолкнуло на мысли создать правильный crypttab — вдруг после этого всё заработает вообще автоматически? Структура, как выше сказано, такая:

plainOpen[LUKS{VG₁( LV_1,1( LUKS[VG₂( LV_2,1(root), LV_2,2(usr), ... )] , ... ))}]

Зелёным помечено то, что, похоже, initramfs способен понять из коробки. Всё остальное — только через кастомные скрипты, если кто-то готов их писать. Казалось бы, если он готов раскручивать LVM, когда встречает его внутри «матрёшки», то всё должно отрабатывать, но этого почему-то не происходит, причины неизвестны. Тестировался вот такой crypttab:где VG сидит на /dev/mapper/cryptroot_crypt. Пробовал убрать всюду initramfs — эффект тот же, ни одного пароля не запрашивается, даже на сам /dev/sdX. В принципе, crypttab достаточно умный, там есть много опций на этот счёт, и всё должно разруливаться, но сидеть и разбираться с этим пришлось бы долго, поэтому забил.

Фиктивный swap убрал c /etc/fstab и даже убил соответствующее LUKS- и LV-устройство принудительно, однако, послеупоминание о нём оказалось выпилено не везде. По крайней мере, теперь он на него пароль не запрашивает, и это уже хорошо. Интересно, откуда initramfs черпает эту swap-специфичную информацию, если в crypptab и fstab её уже нету? Опирается на ранние версии содержимого initramfs?

Кстати, до сих пор не пойму, почему Debian всегда якобы 2 разных ядра ставит, в /boot 2 разных initrd и т.д.

Хорошая новость в том, что тесты убедительно показывают: initramfs'у совершенно пофигу на то, в какие глубины матрёшки запрятана соответствующая VG с рутовой ФС. Пока вы до неё добираетесь, можно назначать любые имена LVM'ам и LUKS-устройствам, это ни на что не повлияет. Чтобы не бояться обновлений, проделал на этой основе способ создания бэкапа: создаём такую же точно структуру на другом диске, но внутренний LUKS, содержащий VG с системой, побайтово копируем туда через dd if=/dev/VG/LV of=/dev/VG2/LV2 (LV2 перед этим создаём точно такого же размера). И всё работает, грузится и взлетает. Можно было бы сделать и через копирование файловых систем, но не хочется разруливать конфликты с несовпадающими UUID'ами, именами volume groups, logical volumes и т.д.

С отсутствием cryptsetup'а в initramfs можно бороться на лету. Если хуки или критерии не срабатывают (сделали update-initramfs -k all -u), тут же редактируем всё снова — lsinitramfs /boot/initrd-... | grep cryptsetup показывает, попал он туда или нет.

Не знаю, кстати, были ли она там когда-то или нет, но в моей версии man initramfs.conf опции CRYPTSETUP не числится.

Когда-то разбирал initrd, вроде туда можно положить что угодно. В дебьяне нельзя ничего делать по общелинуксовому (можно и так, но не рекомендуется), а нужно делать по-дебьяновски. Т.е., если вы вручную распакуете initrd, поправите, запакуете и положите на место, то оно сработает, но предполагается, что за такое кто-то должен бить по рукам, например, очередной апдейт к вашей системе.

Есть /etc/initramfs-tools. Там нужно в подкаталоги в соответствии с их структурой поместить всё, что нужно, поправить там конфиги. Разумеется, на изучение всего этого и на эксперименты нужно потратить достаточно времени, зато потом всё будет работать как часы и можно забыть этот напильник на многие годы.

Затем командой update-initramfs -u все обновления попадут в initrd. И так будет происходить при соответствующих апдейтах системы автоматически.

Может ещё где-то что-то нужно конфигурировать для поддержания initrd, сходу не помню.

Можно попросить туда положить загрузчик TrueCrypt?

Можно, просите.