LINUX.ORG.RU

Монтирование системных дисков с LUKS с использованием ключей на USB носителе

 , ,


0

1

Система Debian Testing. В наличии системный SSD с зашифрованным рутом и еще два отдельных шифрованных диска.

В Debian после введения systemd появились определенные конфликты с монтированием системных дисков с использование ключей. Кое-как по крохам информации в интернете сумел настроить автодекрипт и монтирование дисков при загрузке системы с использованием ключей на usb устройстве.

Что сделано:

# /etc/fstab
/dev/mapper/system--vg-root /               ext4    errors=remount-ro 0       1

# /boot was on /dev/sdb2 during installation
UUID=<uuid> /boot           ext2    defaults        0       2
# /boot/efi was on /dev/sdb1 during installation
UUID=<uuid>  /boot/efi       vfat    umask=0077      0       1
/dev/mapper/system--vg-swap_1 none            swap    sw              0       0

# USB key
LABEL=<label>         /mnt/key        ext4    defaults,nofail,x-systemd.device-timeout=1

/dev/mapper/cdata       /mnt/cdata      ext4    defaults        0       1
/dev/mapper/cvm         /mnt/cvm        ext4    defaults        0       1

# /etc/crypttab
sdb3_crypt /dev/disk/by-uuid/<uuid> /dev/disk/by-label/<label>:/root.key luks,keyscript=/lib/cryptsetup/scripts/passdev
cdata   UUID=<uuid> /mnt/key/cdata.key luks
cvm     UUID=<uuid> /mnt/key/cvm.key luks
# /etc/default/cryptdisks
CRYPTDISKS_MOUNT='/mnt/key'
systemctl mask systemd-cryptsetup@sdb3_crypt.service
update-initramfs -u -k all

Система загружается, диски монтируются. Затем, если просто достаю флешку с ключами, диски cdata и cvm демонтируются. Если предварительно вручную размонтировать usb устройство и только затем вытащить, то все нормально. Как это дело более грамотно обыграть? Каждый раз лезть в консоль и вбивать «sudo umount /mnt/key» очень неудобно.

И вообще, есть здесь люди с похожим сетапом? Как это реализовано у вас? Не покидает ощущение, что у меня костыль на костыле и при каком-нибудь обновлении системы все слетит.

Не думаю, на кой кому-то ключи на постоянно воткнутом USB устройстве? Это же как пароль, только хуже.

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

Согласен. Вся защита сводится к тому, что вломившийся ОМОН не знает, что ключ на флешке.

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

Ну почему же на постоянно воткнутом? Воткнул -> Загрузил -> Достал и убрал. Такой мой сетап, может что-то не так выше написал.

SamuelLJ
() автор топика
Ответ на: комментарий от t184256

Мой стандартный пароль для системного диска составляет около 60 символов. Цифры, буквы, символы, все как надо. Мало того, что надоело его вводить каждый раз, иногда ошибаясь, так еще есть и риск его забыть. Ключи на USB - как минимум удобство, если все верно настроено. Склонировать это устройство и записать на пару дополнительных для сохранности никаких проблем не представляет.

Вся защита сводится к тому, что вломившийся ОМОН не знает, что ключ на флешке.

Да все они знают, не от них защита.

В данном конкретном случае все делается для большего удобства в первую очередь.

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

60 символов пароль от luks!? Ну, ты точно неуловимый джо. Твои данные 100% не представляют интереса для определённого круга лиц, а если будут нужны, то эти люди сделают так, что сам расскажешь. Уменьшай пароль до 8-16 символов. Сколько займёт перебор 12 символ ног пароля? Долгое время.............

anonymous
()

Давно не пользуюсь, и не знаю, насколько актуально, но в 2015-ом было так:

Сегодня я расскажу о том, как подружить Debian, systemd и расшифровку корня ключом на дисковом носителе. Вообще это элементарно, но только не в Debian.

Предположим, что наш ключ это раздел на флэшке /dev/disk/by-partlabel/rootkey, который можно тупо прочесть от начала до конца (оффсеты и прочие возможности cryptsetup systemd поддерживает, насчёт дебиановских костылей не знаю). Тогда в /etc/crypttab мы должны записать что-то типа


root /dev/disk/by-partlabel/debian /dev/disk/by-partlabel/rootkey luks,discard,keyscript=/usr/local/bin/keyscript

Вся суть здесь в keyscript — без него в initramfs просто ни хрена не добавится, и вам придётся чинить систему, хотя такой формат поддерживается везде. Везде, кроме дебиановского скрипта в initramfs. Сам скрипт обязательно должен быть исполняемым и в данном случае может выглядеть хотя бы так:

#!/bin/sh

until test -b $1; do
    sleep 1;
done
/bin/cat $1

Как видите, скрипт делает просто бессмысленную работу. Использовать дистрибутивный passdev не стоит даже если вас устроит ключ на ФС, потому что у этого хелпера свои требования к синтаксису поля с ключом, несовместимые с чем угодно другим, включая systemd После этого делаем update-initramfs и радоваемся.

Работало на 100%.

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

Спасибо, не видел этого мануала. Интересно, но сейчас менять уже не буду. Сохраню, может пригодится.

Если бы увидел раньше, застрял бы вот здесь:

dd if=$USBKEY bs=1 count=1024 | \
У меня ключи просто как файлы лежат. Может, и не самое удачное и секьюрное решение, но так проще с ними работать.

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

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

Спасибо, это видел, когда настраивал систему. Не понравилась необходимость создания каких-то левых и ненужных скриптов. К счастью, с systemd и passdev все-таки можно работать. Выручила, если не ошибаюсь, именно эта команда:

systemctl mask systemd-cryptsetup@sdb3_crypt.service

SamuelLJ
() автор топика

offtopic

  • В Debian можно включить ключевой файл в initramfs при его сборке, погугли, чтобы найти ман, в каком это описано.
  • Для init (sh-скрипт или systemd) в initramfs можешь написать скрипт, который будет делать все, что захочешь.
gdijulsxeh
()
Ответ на: комментарий от SamuelLJ

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

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

Угу. Я даже признаю, что знаю только полумеры и идею с заминированным корпусом сервера, а к этим придраться проблем нет.

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