Можно ли сделать загрузку с зашифрованного корневого раздела с использованием ключа на внешнем носителе (без ввода пароля)? А еще лучше, чтобы /boot находился на том же внешнем носителе.
Насчёт отдельного раздела /boot, это и так работает.
Я думаю, ничего не мешает это реализовать. Сложностью будет то что для монтирования шифрованного раздела придётся ждать не один девайс, а два.
Что нужно прописать в fstab, касающееся зашифрованного корневого раздела (luks), чтобы сгенерировать initrd и раздел примонтировался при загрузке? Или, это как-то иначе делать?
(В ответ на комментарий №3) > Что нужно прописать в fstab, касающееся зашифрованного корневого раздела > (luks), чтобы сгенерировать initrd и раздел примонтировался при загрузке? > Или, это как-то иначе делать? Пожалуйста поясните свой вопрос.
что сделать, чтобы при загрузке монтировался LUKS / раздел ?
(В ответ на комментарий №5) > что сделать, чтобы при загрузке монтировался LUKS / раздел ? Для корня на LUKS процедура создания не отличается от других схем: * Создайте шифрованный рутовый раздел; * Заполните там fstab; * Установите туда make-initrd и make-initrd-luks; * Смонтируйте туда /sys; * Сделайте туда chroot; * make-initrd.
>* Заполните там fstab; Строчку в fstab не подскажите? Я добавил такую строчку: UUID="a07e14e6-7bee-48ac-99ea-39aa168cd44d" / crypt_LUKS defaults 0 0 (подобная строка при "ручном" монтировании командой mount работает, но используется mount.crypt_LUKS) make-initrd вылетает с ошибкой add-module: No module "crypt_LUKS" found for kernel 3.0.3-std-def-alt0.M60P.1 В этом-то и загвоздка, что в мануалах пишут про crypttab+fstab, а crypttab у нас то ли не работает, то ли я как то не так его "готовлю".
Вот еще текст письма из рассылки: Спасибо, но сложность, похоже, именно alt-specific Такая строчка в /etc/crypttab _dev_sdb2 UUID="a07e14e6-7bee-48ac-99ea-39aa168cd44d" none luks устройства в /dev/mapper/ не создаёт. Такая строчка в fstab UUID="a07e14e6-7bee-48ac-99ea-39aa168cd44d" /mnt/sdb2 crypt_LUKS defaults 0 0 позволяет монтировать устройство командой "mount /mnt/sdb2". Но используется, в данном случае, mount.crypt_LUKS из пакета pam_mount. Но сгенерировать initrd командой make-initrd (соответственно точка монтирования -- корневой раздел) не получается: add-module: No module "crypt_LUKS" found for kernel crypttab у нас обрабатывается? Если да, то какой формат записи? Если нет, то что писать fstab, чтобы make-initrd было понятно?
(В ответ на комментарий №7) > >* Заполните там fstab; > Строчку в fstab не подскажите? Сейчас предполагается, что в fstab будет уже /dev/mapper/... т.е. уже расшифрованный раздел. > make-initrd > вылетает с ошибкой > add-module: No module "crypt_LUKS" found for kernel 3.0.3-std-def-alt0.M60P.1 Это понятно. make-initrd пытается по fstab узнать модуль файловой системы. Я попробую определить его иначе, чтобы работало более железно.
> Сейчас предполагается, что в fstab будет уже /dev/mapper/... т.е. уже > расшифрованный раздел. /etc/crypttab обрабатывается? Если нет, то где нужно прописать, что корневой раздел требует расшифровки? > Это понятно. make-initrd пытается по fstab узнать модуль файловой системы. > Я попробую определить его иначе, чтобы работало более железно. Не могли бы вы описать как на данный момент (менее железно :)) можно настроить систему, чтобы при загрузке монтировался корневой раздел. Потому как в других системах зашифрованный раздел нужно прописывать в crypttab, а в ALT это эффекта не дало и непонятно как нужно делать.
(В ответ на комментарий №10) Прежде всего хотел бы оправдаться :) Я не мантейнер cryptsetup: $ giter acl sisyphus cryptsetup show cryptsetup naf shaba я его использую, но не для рутового раздела и несколько нестандартно. И второе, make-initrd-luks создавал kas@ для своих конфигураций, но некоторое время назад он покинул наш проект (sisyphus, altlinux). Я лишь создавал ядро make-initrd. > /etc/crypttab обрабатывается? Если нет, то где нужно прописать, что корневой > раздел требует расшифровки? Статус /etc/crypttab стоит обсуждать не в этой баге :) > Не могли бы вы описать как на данный момент (менее железно :)) можно настроить > систему, чтобы при загрузке монтировался корневой раздел. Потому как в других > системах зашифрованный раздел нужно прописывать в crypttab, а в ALT это эффекта > не дало и непонятно как нужно делать. Можно обойтись без автодетекта и прописать всё руками, но если это не горит не наш метод :)
(В ответ на комментарий №11) Дело ясное, что дело тёмное :) >Статус /etc/crypttab стоит обсуждать не в этой баге :) На какие еще пакеты нужно развесить фич реквесты или баги, чтобы дело могло сдвинуться? >Можно обойтись без автодетекта и прописать всё руками, но если это не горит не >наш метод :) Вы имеете ввиду образ initrd.img распаковать и внести изменения? Это интересно. Если не трудно, не могли бы вы описать какие изменения там нужно сделать?
(В ответ на комментарий №12) > На какие еще пакеты нужно развесить фич реквесты или баги, чтобы дело могло > сдвинуться? Вам стоит пообщаться с мантейнерами cryptsetup на тему поддержки crypttab. > Вы имеете ввиду образ initrd.img распаковать и внести изменения? Это интересно. Нет :) Я конечно не люблю людей, но не до такой степени. > Если не трудно, не могли бы вы описать какие изменения там нужно сделать? make-initrd на самом деле состоит из нескольких частей: автоугадав конфигурации и механизма, который собственно создаёт initrd. Сейчас у вас угадав не может автоматически определить конфигурацию, но это можно сделать вручную. Для этого в /etc/initrd.mk укажите: AUTODETECT = common resume FEATURES = luks # модуль для файловой системы MODULES_ADD = ext4 # Алгоритм шифрования. Если у вас sha256, то можно это не писать. LUKS_HASHES = twofish-generic и попробуйте сгенерировать inird с таким конфигом.
> Для этого в /etc/initrd.mk укажите: Попробую. А что в данном случае нужно писать в /etc/fstab? /dev/mapper/что? UUID?
(В ответ на комментарий №14) > > Для этого в /etc/initrd.mk укажите: > Попробую. А что в данном случае нужно писать в /etc/fstab? То что будет в fstab для make-initrd уже не важно. Он в него смотреть не будет. > /dev/mapper/что? > UUID? Если вы пропишите UUID в fstab от /dev/mapper/что и укажете в fstab её файловую систему, то тогда если вы сделаете чрут на неё и выполние make-initrd, то автодетект определит, что у вас рут на зашифрованном разделе и тогда мой приведённый initrd.mk не нужен. Автоматика будет работать.
Есть ещё один момент: текущая реализация (если я всё окончательно не забыл) будет пытаться расшифровать все разделы, что в общем случае не верно. Нужно на этапе автодетекта фиксировать какой путь нужно пройти что бы получить рашифрованый root.
(В ответ на комментарий №16) > Есть ещё один момент: текущая реализация (если я всё окончательно не забыл) > будет пытаться расшифровать все разделы, что в общем случае не верно. Нужно на > этапе автодетекта фиксировать какой путь нужно пройти что бы получить > рашифрованый root. На самом деле ты реализовал параметр luksdev, который если выставлен указывает какое устройство искать: http://git.altlinux.org/people/legion/packages/make-initrd.git?p=make-initrd.git;a=blob;f=features/luks/data/lib/filters/luks;h=ea7fe7f7f2fe4eea9553854f84d59bf2a59b9247;hb=c914c9685dd20f4318848c1bf82512de0e3cbbab#l10 но забыл указать, что этот параметр нужно слушать. Поэтому сейчас его нельзя указать.
> Если вы пропишите UUID в fstab от /dev/mapper/что и укажете в fstab её файловую > систему, то тогда если вы сделаете чрут на неё и выполние make-initrd, то > автодетект определит, что у вас рут на зашифрованном разделе и тогда мой > приведённый initrd.mk не нужен. Автоматика будет работать. Спасибо, почти получилось. Сделал как вы написали. Действительно автоматика сработала. Теперь, при загрузке меня спрашивают пароль. Я его ввожу, но система не дожидаясь окончания ввода пишет: No key available with this passphrase. Проверил несколько раз. После первого введённого символа перескакивает на новую строку и "ругается".
Если это как-то может помочь, то в последнем openSUSE зашифрованный корневой раздел монтируется корректно.
В дополнение к комментарию №18 http://s014.radikal.ru/i326/1112/7b/c8550de1ffd9.jpg Как видно из скриншота если продолжить и вручную сделать cryptsetup luksOpen из под initramfs, то раздел подключается. Баг?
(В ответ на комментарий №20) > cryptsetup luksOpen из под initramfs, то раздел подключается. > Баг? в момент монтирования выполняется команда: cryptsetup --key-file=- luksOpen /dev/sda2 sda2-luks не могли бы вы выполнить её вручную ?
> cryptsetup --key-file=- luksOpen /dev/sda2 sda2-luks Enter passphrase: (initramfs) ls /dev/mapper control sda2-luks Пароль вводится, том подключается. Кстати, а по поводу --key-file не могли бы уточнить? Где можно указать путь к key-file, чтобы initramfs сгенерировалась соответствующим образом для монтирования не по паролю, а по ключу? Однако, конечно, хотелось бы решить вопрос с вводом пароля.
(В ответ на комментарий №22) > Пароль вводится, том подключается. Скверно. > Где можно указать путь к key-file, чтобы initramfs сгенерировалась > соответствующим образом для монтирования не по паролю, а по ключу? Это ещё предстоит реализовать. > Однако, конечно, хотелось бы решить вопрос с вводом пароля. Мне тоже интересно почему оно так себя ведёт kas@ ?
а что stdin в этом месте? попробуйте убрать --key-file=- вообще. он должен спросить с терминала по-умолчанию.
(В ответ на комментарий №24) > а что stdin в этом месте? попробуйте убрать --key-file=- вообще. он должен > спросить с терминала по-умолчанию. Кажется я знаю в чём дело. Сейчас я сделал так, что /dev/console открывалась сразу в init. aebirukov@, вы можете проверить версию make-initrd из git ?
Проверил. Не помогло.
(В ответ на комментарий №26) > Проверил. Не помогло. Простите за задержку. Сегодня создал зашифрованный с паролем раздел и загрузился с него в qemu. Пароль ввёлся весь.
> Пароль ввёлся весь. Странно. Посмотрите, пожалуйста, что не так. Все действия из под VirtualBox. Установлен ALTLinux 6.0, скопирован на зашифрованный раздел. Затем, загрузился с livecd и: [root@localhost ~]# mount /dev/sda2 /mnt/ Password: [root@localhost ~]# mount /dev/sda1 /mnt/boot/ [root@localhost ~]# mount --bind /dev/ /mnt/dev/ [root@localhost ~]# mount --bind /proc/ /mnt/proc/ [root@localhost ~]# mount --bind /sys/ /mnt/sys [root@localhost ~]# cd /mnt/ [root@localhost mnt]# chroot /mnt/ [root@localhost /]# rpm -q make-initrd make-initrd-0.6.2-alt1 [root@localhost /]# rpm -q make-initrd-luks make-initrd-luks-0.6.2-alt1 [root@localhost /]# make-initrd Guessed features: add-modules cleanup compress devmapper luks Adding LUKS support ... Image is saved as /boot/initrd-3.0.3-std-def-alt0.M60P.1.img [root@localhost /]# cat /etc/fstab UUID="2829eb20-0787-499a-97e6-aceceeefb46a" /boot ext2 defaults 00 # /dev/mapper/_dev_sdb2 UUID="7cda95cd-bc1a-4676-b91a-a1bcdf2e6b87" / ext4 defaults 0 0 [root@localhost /]# grub-mkconfig -o /boot/grub/grub.cfg
Дополнение: Сейчас попробовал выбрать в меню grub (failsave mode) Пароль ввёлся весь, но загрузка дальше не идёт. Остановилась на строчке: initrd: udev: Running luks handler ... http://s15.radikal.ru/i188/1112/2f/3727311ac805.jpg
Еще дополнение: http://s15.radikal.ru/i189/1112/b9/e219726673a6.jpg
Я к сожалению не знаю про VirtualBox ... я проверял на qemu из сизифа. Проверьте, правильный ли вы указали root=UUID=... т.е. указали ли вы UUID от /dev/mapper/... ?
> Я к сожалению не знаю про VirtualBox ... я проверял на qemu из сизифа. Вряд ли может быть разница. Тем более, что failsafe пароль вводить даёт. В чем же дело? > Проверьте, правильный ли вы указали root=UUID=... т.е. указали ли вы UUID от > /dev/mapper/... ? Да, проверил. /dev/sdb2: UUID="a07e14e6-7bee-48ac-99ea-39aa168cd44d" TYPE="crypto_LUKS" /dev/mapper/_dev_sdb2: UUID="7cda95cd-bc1a-4676-b91a-a1bcdf2e6b87" TYPE="ext4" [root@host-15 etc]# cat /etc/fstab|grep 7cda UUID="7cda95cd-bc1a-4676-b91a-a1bcdf2e6b87" / ext4 defaults 0 0 Вы проверяли на версии make-initrd из Сизифа или git? Или они сейчас одинаковые?
(В ответ на комментарий №32) > /dev/sdb2: UUID="a07e14e6-7bee-48ac-99ea-39aa168cd44d" TYPE="crypto_LUKS" > /dev/mapper/_dev_sdb2: UUID="7cda95cd-bc1a-4676-b91a-a1bcdf2e6b87" TYPE="ext4" > [root@host-15 etc]# cat /etc/fstab|grep 7cda > UUID="7cda95cd-bc1a-4676-b91a-a1bcdf2e6b87" / ext4 defaults 0 > 0 Это всё хорошо, но что вы в bootloader'е прописываете в cmdline ?
> Это всё хорошо, но что вы в bootloader'е прописываете в cmdline ? Ничего, а надо что-то?
(В ответ на комментарий №34) > > Это всё хорошо, но что вы в bootloader'е прописываете в cmdline ? > Ничего, а надо что-то? Разумеется. Если вы выполните команду "cat /proc/cmdline" на загруженной системе, то увидите с какими параметрами было загружено ядро. В частности вы увидите, что передаётся параметр root=ЧТО_ТО, где ЧТО_ТО указывает тем или иным образом на корень. Эта информация не "прошивается" в initrd при его создании. Один и тот же initrd может использоваться для загрузки с разных источников корневой файловой системы. Так же могут указываться другие параметры, которые управляют поведением initrd и/или последующей системой. Пропишите в загрузчик параметр root=UUID=7cda95cd-bc1a-4676-b91a-a1bcdf2e6b87 (прямо как я указал).
>(прямо как я указал). Спасибо, огромное - с Божьей помощью и помощью legion@ мне удалось таки загрузиться с корневого зашифрованного раздела :) В grub.cfg убрал опцию quiet=1, именно она не давала вводить пароль полностью. Теперь всё работает. Получается "автоматика" в части make-initrd работает хорошо. grub.cfg правильный автоматом не генерируется. Request сделать? Теперь хотелось бы вернуться первоначальному вопросу. Вход по ключу, а не по паролю реально сделать? Пусть даже не автоматом пока. Где нужно что поправить?
(В ответ на комментарий №36) > Получается "автоматика" в части make-initrd работает хорошо. grub.cfg > правильный автоматом не генерируется. Request сделать? Это не задача make-initrd. У нас есть пакет bootloader-utils, утилиты которого вызываются при обновлении ядра и именно они обновляют записи в загрузчиках (grub или lilo). Когда вы руками меняете схему загрузки, то никакой автоматики не будет. > Теперь хотелось бы вернуться первоначальному вопросу. Вход по ключу, а не по > паролю реально сделать? Пусть даже не автоматом пока. Где нужно что поправить? Пока это сделать нельзя т.к. make-initrd работает таким образом, что не может ждать нескольких устройств сразу. Я думаю над этой проблемой и багу не закрываю.
>(grub или lilo). Да, я это и имел ввиду. На уже рабочей системе при попытке сгенерировать grub.cfg: # grub-mkconfig -o /boot/grub/grub.cfg /usr/sbin/grub-probe: error: cannot stat `/dev/sdb2-luks'. Но если поставить символическую ссылку на /dev/mapper/sdb2-luks, то генерация проходит успешно. Машина загружается. (Правда у меня почему-то из под VirtualBox работает только когда vga=normal, надо вживую потестировать.)
> Пока это сделать нельзя т.к. make-initrd работает таким образом, что не может > ждать нескольких устройств сразу. Я думаю над этой проблемой и багу не > закрываю. А если ключ размещать на /boot разделе. А /boot раздел на flash накопителе? Он ведь уже подмонтирован - его ждать не надо. Вроде, удобно. Как вы считаете?
Это зависит от задачи. На своём рабочем ноуте я держу /home на внешнем шифрованном носителе, а корень системы на обычном разделе.
> Это зависит от задачи. На своём рабочем ноуте я держу /home на внешнем > шифрованном носителе, а корень системы на обычном разделе. Т.е. используя текущий make-initrd уже можно реализовать схему с ключом размещённым на разделе /boot? Если не трудно, не могли бы вы описать как это сделать?
(В ответ на комментарий №37) > > Теперь хотелось бы вернуться первоначальному вопросу. Вход по ключу, а не по > > паролю реально сделать? Пусть даже не автоматом пока. Где нужно что поправить? > > Пока это сделать нельзя т.к. make-initrd работает таким образом, что не может > ждать нескольких устройств сразу. Средствами make-initrd реализовать схему с ключём пока нельзя.
> Средствами make-initrd реализовать схему с ключём пока нельзя. А мне это удалось. # ls -l /etc/root.key -rw------- 1 root root 56 Дек 23 21:05 /etc/root.key # cat /etc/initrd.mk.d/key.mk include /etc/initrd.mk IMAGE_SUFFIX = -key PUT_FILES += \ /etc/root.key $ cat make-initrd-0.6.2/features/luks/data/lib/handlers/050-luks #!/bin/sh . /scripts/functions KEY="/etc/root.key" nameluks= password= handler() { nameluks="${INIT_LUKS##*/}-luks" # skip if $nameluks has already exist dmsetup info "$nameluks" >/dev/null 2>&1 && return 0 ||: if [ -e $KEY ]; then cryptsetup --key-file=$KEY luksOpen "$INIT_LUKS" "$nameluks" else cryptsetup luksOpen "$INIT_LUKS" "$nameluks" fi retcode="$?" if [ "$retcode" != "0" ]; then error "Unable to activate LUKS: $retcode" return 1 fi } rc=0 for e in "$handler_eventdir"/luks/*; do [ -f "$e" ] || break ( . "$e"; handler; ) || rc=1 done exit $rc Как легко понять, принцип в том, что root.key запаковывается в образ initramfs, а там считывается слегка изменённым make-initrd-luks. Если root.key в образе найден не будет - система будет ожидать ввода пароля. /boot следует размещать на внешнем носителе. Собственно, этот носитель и будет ключом.
В git добавлена поддержка загрузки с шифрованным корнем на LUKS и ключём от этого раздела на внешнем носителе. Для этого добавлен ключ: luks_key=<path> luks_key=<path>:<keydev> luks_key=<path>:<keydev>:<luksdev> path - путь до ключа, если keydev не задан, то этот путь на самом initrd; keydev - устройство на котором находится ключ. Оно задаётся как и root= т.е. UUID=<uuid> или LABEL=<label> ... luksdev - раздел для которого нужно применить ключ.
> path - путь до ключа, если keydev не задан, то этот путь на самом initrd; > keydev - устройство на котором находится ключ. Оно задаётся как и root= т.е. > UUID=<uuid> или LABEL=<label> ... > luksdev - раздел для которого нужно применить ключ. С ключом интегрированным в initrd -- работает. USB накопитель с ключом что-то у меня не монтируется. И по UUID и по LABEL пробовал luks_key=/etc/root.key:UUID=00f42648-1a35-4c60-a7f3-59727e7c6834 luks_key=/etc/root.key:LABEL=bootkeyflash Так хоть пишу? Останавливается на udev: что-то там luks handler
(В ответ на комментарий №45) > USB накопитель с ключом что-то у меня не монтируется. FEATURES += usb ? > Так хоть пишу? Да.
> FEATURES += usb Работает, Спасибо.
Исправлено.
