pam_mount

в инитрамфс, по идее, нормально - она же зашифрована тоже будет

а нафига, если не секрет, шифровать что-то кроме home и var?

Зачем шифровать /boot ?

Помести ключ от / на /boot.

В /etc/fstab могут засветиться пароли для sshfs. С настройками davfs такая же фигня (не помню уже точно, где его конфиг, но вроде тоже в /etc).

Так что как минимум смысл шифровать /etc определённо есть.

Точно, самый простой вариант. Буду юзать отдельный шифрованный раздел под /boot, остальное на LVM поверх LUKS.

l -l/home

crown -R etc.: ~etc.

э-э-ээ, в чём проблемы, то??

Эмм...

http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/

в разделе - Bonus: Login once

Что это решает? Я не понял.

Я юзаю, ключ храню в initramfs.

В /etc/fstab могут засветиться пароли для sshfs.

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

Нет, этот вариант ничем не проще одного раздела. Только неудобнее.

Если ты о том, что лучше использовать ключи, то кто ж спорит. Но вот если хочешь подмонтировать Яндекс.Диск через davfs, то придётся указывать пароль либо вводить его каждый раз заново, потому что он в ключи не умеет.

// Держу зашифрованным всё, кроме /boot, что позволяет не париться о том, что кто-то без меня увидит пароль в /etc. По крайней мере, тот, кто увидит его там, с тем же успехом и гораздо больше всего увидел бы в ~/.mozilla.

Держу зашифрованным всё, кроме /boot

Да какой в этом смысл, а? Шифруй весь диск и все. Минусов нет, одни удобства.

Держу зашифрованным всё, кроме /boot, что позволяет не париться о том, что кто-то без меня увидит пароль в /etc

У меня для тебя плохие новости. Если не можешь осилить положить secrets в secrets-файл, то тебя сделает любой nobody.

Поясни, плиз. Интересно стало.

Не клади пароль в fstab, шифруй весь диск без этого дурацкого тренда на отдельный /boot. Что пояснить-то?

Есть актуальный манул для Debian/Ubuntu? Года три назад ни хрена не работало - то ли руки из жопы, то ли неудачная версия GRUB2 была. И можно ли использовать ключ на флэшке с GRUB2?

Прикинь, да. На праздниках следовал вот этим своим заметкам с debian testing — все работает, включая hibernate на шифрованный swap.

# cryptsetup luksFormat /dev/sda1 # Enter password
# cryptsetup open /dev/sda1 root
# mkfs.btrfs /dev/mapper/root -LMANDARIN
# BURN # unpack rootfs
# cryptsetup luksHeaderBackup --header-backup-file /etc/mandarin.header.luks.bak
# chmod 000 /etc/mandarin.header.luks.bak
# cryptsetup luksAddKey /dev/sda1 /etc/mandarin.key
# GRUB_ENABLE_CRYPTODISK=y
# /etc/crypttab:
# <target name> <source device> <key file>              <options>
# root          /dev/sda1       /etc/mandarin.key       luks,keyscript=/bin/cat,discard
# in /usr/share/initramfs-tools/scripts/local-top/cryptroot:162
#   comment "#message "cryptsetup: lvm is not available"
#
# sudo cryptsetup luksFormat /dev/sda2 --key-file=/etc/mandarin.key
# sudo cryptsetup open /dev/sda2 swap --key-file=/etc/mandarin.key
# sudo mkswap /dev/mapper/swap -L MANDARINSWAP
# swap            /dev/sda2       /etc/mandarin.key       luks,keyscript=/bin/cat
# LABEL=MANDARINSWAP none swap    sw
# /etc/initramfs-tools/conf.d/resume: RESUME=/dev/mapper/swap
#
# initramfs xz compression, modules=dep, update-initramfs -kall -u
# install grub

Два момента не понял:

1) Как ключ пихается в initramfs? Каким-то стандартным хуком в соответствии с полем в crypttab?

2) В GRUB2 всё равно придётся вводить пароль, так?

Ой, черт, хук нестандартный, но у меня он разворачивается через salt и уже есть в rootfs, поэтому в этих заметках о нем ни слова.

$ cat /etc/initramfs-tools/hooks/inject-key 
#!/bin/bash
mkdir -p "${DESTDIR}/etc" || true
if [ -e /etc/cola.key ]; then cp /etc/cola.key "${DESTDIR}/etc/"; fi

Пароль да, все равно придется вводить. В этом вроде как весь смысл.

Спасибо, в выходные попробую.

В этом вроде как весь смысл.

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

для особо одарнутых повторюсь,

ЭТО вывод поимённо пользователей (владельцев), а «etc.» (в моём примере ЭТО ИМЯ И М Я И М Я), так доходит, ну хоть чуточку?

Нет.

Это что, волшебным образом начинает шифровать пароли davfs? Нет. О чём речь вообще?

Я уж лучше поввожу, но чтобы /boot был в /.

А смысла в ключе я не вижу. Если я посею ноут, то с ключом.

Я смысл вижу, и вроде нашёл способ: нужно использовать команду cryptomount. Буду экспериментировать в виртуалке для начала…

от SUDO, пароль то шифруется?

«Волшебным образом» я указал в примере «например»(!), (в этом смысле).

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

Вот тут я реально перестал парсить фразы, раньше хоть надежда была.

я не понял, SUDO, не вводишь что-ли!?

В этом был смысл сокраментального ВОПРОСА,да, что уж там, и примера, а, уж слово «парсить» к слову фразы я даже как кибернетик никогда не приставил, или ты такой тонкотелый троллейбус?

и вроде скобок напихал, а не помогает.

задолбался уже объяснять

Что я хочу по пути «Имя» решить эту задачу, он же толдычит про dav, и, что какой-то там Яндекс не жрёт ключи от линя, который как я понял, нахрен им не сдался, вообще!

Я изначально всего лишь отвечал на этот кусок комментария:

а нафига, если не секрет, шифровать что-то кроме home и var?

и пояснил, что секретного может оказаться в /etc, то есть в «чём-то кроме home и var».

Сейчас проверил в своём initrd.img — /etc/fstab там внутри нет же, следовательно (если не считать сценария с подменой /boot) шифрование всего кроме /boot довольно неплохо защищает всё секретное, что мне нужно.

Извините за некрофилию

В общем, сделал, работает нормально. Собственно пишу на всякий случай, вдруг пригодится: поддержка ключей в initramfs теперь есть из коробки, подробности в /usr/share/doc/cryptsetup/README.initramfs.gz, п.12.