Можно ли открыть криптоконтейнеры FreeOTFE под Linux?
Во времена, когда я был заядлым виндузятником я юзал FreeOTFE http://www.pgpru.com/soft/freeotf
Сейчас задаюсь вопросом, можно ли открыть криптоконтейнеры FreeOTFE под Линукс?!
Ссылки
[link1] https://www.pgpru.com/proekt/wiki/rasshirennyjjsintaksis#h22-5
[link2] http://www.google.com/search?ie=windows-1251&oe=windows-1251&q=cryptsetup%2Bhowto
[link3] http://feraga.com/library/howto_use_cryptsetup_with_luks_support_0
[link4] https://www.pgpru.com/comment36260
[link5] http://en.wikipedia.org/wiki/Ext4#Disadvantages
[link6] https://www.pgpru.com/faq
[link7] https://www.pgpru.com/novosti/2008/vzlomgrubojjsilojjparoljvypytanizpodozrevaemogopoliciejj
[link8] https://www.pgpru.com/faq/zaschitadiska#h42-14
Насколько понимаю, FreeOTFE создаёт контейнеры в формате loop-устройств cryptsetup-LUKS. Соответственно, последним и нужно пытаться открывать.
То – не то?
Оно самое.
а в этом нет ничего зловредного со стороны этого пакета?!
Пакет ставится из официального репозитория? GPG-подпись верна? Мейнтейнеры же не ССЗБ.
Если Вы про initramfs, то это на случай, если захотите шифровать всю систему, включая корневой раздел.
Из официального, руками подпись не проверял, аптитуда не орет на то, что подписано не той подписью.
Спасибо, понял, именно про это.
P. S. А чем Вы рекомендуете шифровать существующие разделы под Linux?!
Тем же dmcrypt-cryptsetup-LUKS. Это типа как стандартное решение.
Аптитуда в последних Дебьянах не даёт поставить пакет с неверной подписью, если только рут сам не внесёт дополнительный ключ в конфиг и в базу коммандой apt-key add, так что вручную проверять не нужно.
Да и это было бы несколько затруднительно. В стародавние времена для этого существовали скрипты, скачивающие, но не устанавливающие пакеты, считающие от него хэш, сверяющие по списку хэшей пакетов и уже от этого списка сверяющие общую подпись. Сейчас проверка принудительна, автоматизирована, прозрачна и изкаробочна.
Кроме того, шифрование тесно интегрировано в систему, так чтобы можно было шифровать физические тома и RAID-массивы, которые могут цепляться при старте, так что пароль или ключ с флэшки могут вводиться до старта init (когда утилиты недоступны с корневого раздела), для этого вносятся все необходимые компоненты в рамдиск, который соответственно и перепаковывается.
Установил cryptsetup, прочитал ман, совершенно туплю и не могу понять – как открывать файл криптоконтейнера, созданный под FreeOTFE?! Ман какой-то совершенно лапидарный и не дает никакого представления...
Видимо, как-то так:
У меня в /dev/mapper есть только:
Надо создать руками соответствующие девайсов?
Когда выполните третью команду, появится всё, что нужно.
А обратно размонтировать таким образом?
Проще:
SATtva, на базе того, что ты написал, создал скриптик loset :
Запускаю, такая фигня:
Пароль точно правильный, только что грузился в винду, все открывалось.
А устройство получается надо создавать все-таки?
Ничего не создалось, несмотря на то, что ты написал...
Когда просто выполняю команды в комстроке выходит только что нет ключа для парольной фразы.
Под FreeOTFE я создавал файлы криптоконтейнеров (расширение у них .vol) без отдельного файла ключа, т.е. ключ храниться также в этом файле.
Получается, что линукс по какой-то причине не читает этот ключ, или как это понимать?
Кидайте сюда распечатку (дамп) того, что выведет такой набор комманд:
Извиняюсь, в последней строке просто:
Но скорее всего результат будет таким же плачевным: устройство не распознается как LUKS-рздел и /dev/mapper/somename не создастся (вручную его создавать не нужно, оно должно возникать и исчезать только автоматом при правильной работе соотв. комманд — это принципиально). Тогда значит FreeOTFe создало несовместимый контейнер (как вариант). А в самом Линуксе с помощью cryptsetup у вас контейнеры создаются и открываются?
Если верить SATtva (см. выше), оно вроде так не должно было сделать.
Еще не пробовал. У cryptsetup man очень лапидарный, никак не могу его вкурить.
Гость (18/01/2010 02:40), цитаты выделяются так[link1]: <[ Цитируемый текст ]>
По крайней мере, так заявляют сами разработчики FreeOTFE. Может оно по умолчанию несовместимо, а для совместимости надо создавать как-то по-особому?
В Сети тонны howto по его использованию, воспользуйтесь гуглом. google:cryptsetup+howto[link2]
Хочу вступиться за cryptsetup, его специально делали как очень простую и доступную систему шифрования. В man важно обратить основное внимание на часть, касающуюся LUKS, она очень ясно изложена, большинство опций на первых порах можно оставлять по умолчанию.
Наверное, нюанс в том, что без понимания loop-устройств, создания и монтирования файловой системы в файле сделать что-то одним cryptsetup'ом довольно трудно. Философия GNU: каждая программа — отдельный узкоспециализированный кирпичик в единой цельной системе.
Изучил вот этот howto : http://feraga.com/library/howt....._with_luks_support_0[link3]
Пытаюсь создать криптоконтейнер:
Не хочет создаваться.
По тому же хауту пытаюсь открыть криптоконтейней, созданный под FreeOTFE:
– не хочет воспринимать пароль.
Посмотрите внимательно, о чём Вас просит cryptsetup:
Из-за критичности операции, которая способна повлечь уничтожение данных на целевом разделе, нужно ввести "YES" заглавными буквами.
SATtva, благодарю, все работает. Прошу прощения за тупость :)
Единственно что не получается открыть FreeOTFE, видимо, попробовать написать им?
P. S. А как мне зашифровать, скажем, /home? Я так понимаю, что если я натравлю на /dev/cdaX, на котором /home, cryptsetup, то он сотрет все данные. Я так понимаю, что никак по-другому, кроме как скопировав или заархивировав их, потом зашифровав раздел с утерей всех данных, и записью на него из созданной копии/архива, вариантов нет?
А что касается создания шифрованных разделов на стадии установки Linux, скажем, с дебиановских дисков, так скорее всего именно LUKS и применяется?
И в чем принципиальная разница между LUKS и, скажем, Truecrypt? Чем последняя лучше или хуже?
Там всё-таки много чего, что лучше читать по манам и статьям.
Общая картина такова.
Рекомендуется отказаться от разбиения на разделы /dev/sda1, /dev/sda2 и т.д. Разделы как-бы теперь устарели и используются только для размещения разных ОС на одном винчестере или в экономных встраиваемых системах.
Остаётся только раздел под /boot и под всё остальное. Всё остальное форматируется в LVM. Вместо разделов, внутри физического тома LVM используются логические тома, которые можно двигать, изменять размеры вместе с данными (даже когда используется шифрование тома), делать снэпшоты не останавливая сервер.
При инсталляции Debian всё по такой схеме с томами и предлагает ставиться, при этом LUKS интегрирован в LVM и вы можете зашифровать любой физический том со всеми логическими или отдельно логические тома.
Альтернатива LUKS — loop-aes, его лучше не выбирать, он по ряду причин считается тупиковым направлением.
Truecrypt — не GPL-лицензия, а какая-то самопальная (в Debian её обозвали юридической миной замедленного действия и TC в дистр не включили).
Плюсы у него только в создании контейнеров без заголовков (чистый рэндом), что производит большое впечатление на новичков — "теперь они ничего не поймут и не докажут!" (в большинстве случаев такая защита — "страус спрятался в детской песочнице").
Более серьёзный плюс — отрицаемое шифрование, скрытые вложенные контейнеры.
Всё это неплохо, надо просто понимать ограниченность этих плюсов.
Зато связка "{kernel-cryptoAPI-cryptsetup-LUKS} over LVM" — чисто линукс-ориентированный продукт с хорошим теоретическим обоснованием того, что касается шифрования, с лучше всего изученным и аккуратным открытым кодом.
Не хотелось бы мне переинсталлироваться, а желание зашифровать данные, которые могут быть интересны врагу в случае всяких нехороших против меня действий (не дай Бог!) есть.
Что в этой ситуации лучше сделать – закриптовать /home? Что еще может быть критическим?
Файловые системы у меня выглядят так:
Кстати, а раздел в fat32, оставшийся мне в наследство от винды, я смогу закриптовать с помощью LUKS?
P. S. И все-таки, можно закриптовать существующий раздел, или только сносить его, предварительно скопировав инфу, перезаписывать после создания криптораздела?
Только так. Вот как это делается: http://vladmiller.info/blog/index.php?comment=113
SATtva, большое спасибо, попробую применить на практике, как только появиться время.
Хотел бы задать несколько еще вопросов, можно?
1) Обязательно ли создавать файл, который будет использован для создания криптоконтейнера, именно с помощью dd, как в вышеприведенном howto? Или можно создавать также и с помощью cat, touch и т.п. команд?
2) какие файловые системы можно в принципе и какие лучше использовать для криптоконтейнеров? (В howto предлагается создавать в ext2, это обязательно, или просто пример?)
Конкретно для создания контейнера cat и touch не подходят, т.к. создают пустой файл. Для контейнера необходим файл определённого объёма, который и будет определять ёмкость контейнера (учтите, нужно создавать контейнер большего объёма, чем Вы рассчитываете получить доступного места внутри, поскольку некоторую долю отъест структура файловой системы и неполные блоки).
Можно — любые. Для долгосрочного хранения больших объёмов данных лучше подойдут журналируемые ФС. Лично меня raiserfs и ext4 устраивают.
А размер блоков имеет значение? В привиденном примере, я так понял, он равен 1 Кб. Почему его не сделать, скажем, стандартным 512?
Чем меньше блок, тем ниже производительность, но и меньше издержки на незаполненные блоки. Если предполагается хранить в ФС огромное количество мелких файлов, лучше выбрать небольшой блок. Напротив, если будут храниться в основном большие файлы, блок должен быть большим.
SATtva, прошу прощения за несколько оффтопичный вопрос, Вы написали, что юзаете для этих целей ext4. Вроде бы совсем недавно, в конце 2009 года, народ писал, что она еще нестабильна, и кто-то терял на ней данные, разрабы ее уже докурили?
И такой уже не оффтопичный вопрос, как-то под содержимому файла враг может понять, что он – криптоконтейнер, созданный с помощью LUKS?
Если у криптоконтейнера нет сигнатур, то он может видеть только много высокоэнтропийных данных. С точки зрения постороннего лица есть некоторая вероятность, что эти данные появились не из-за криптоконтейнера, а из-за затирания диска случайными данными, или же там находился большой архив, или кусок длинного фильма...
Гость, мы же с вами (?) это уже обсудили на предыдущей странице — есть комманда luksDump[link4], которая всё показывает. Сигнатуры LUKS открытые. Реально сокрытие сигнатур мало что даёт на практике.
Исправлено[link5] в ядрах от .30 и выше.
А что, их фрагменты действительно неотличимы?
Неотличимы при внешнем осмотре в байтовом отображении. Но отличимы при анализе. Хотя бы грубой силой — методом перебора всех кодеков медиафайлов или архиваторов, специально рассчитанном на работу с кусками данных.
Если я хочу создать шифрованные lvm-разделы на уже установленном Debian, это возможно? (В настоящее время разделы в нем нешифрованные и не-lvm).
Как я понимаю, логические диски lvm – это тоже устройства в /dev/mapper, как и криптованные, и, видимо, и те и другие как то связаны с dm? Как это "скомпоновать"?
Соответственно, еще такие вопросы:
1) Что касается самого закрпитования дисков, нашел два хауту:
http://www.saout.de/tikiwiki/tiki-index.php?page=HOWTO
http://feraga.com/library/howt....._with_luks_support_0[link3]
Хотел бы уточнить, если я криптую раздел посредством команды cryptsetup -y create home /dev/hda9 типа как в первом хауту – это не LUKS?
И чем этот формат хуже или лучше LUKS?
2) Правила второго хауту для создания в лукс-формате применимы не только к криптоконтейнерам в виде файлов, но и к разделам? (Вроде бы там написано, что к файлам и разделам, но в примерах везде речь идет о файлах).
3) Если я захочу поставить еще одну ОС, но чтобы она имела доступ к закриптованному под первой ОС хомяку, что надо делать?
Это не рекомендуется делать. вам придётся уменьшить размер какого-либо раздела программой parted. При этом существует риск потери данных. LVM был придуман как-раз в том числе для того, чтобы изменение разделов было естественной и более безопасной процедурой. Свободное место, созданное программой parted можно отформатировать как физический том, а внутри него создавать логические.
Криптованный логический том — это двойник шифрованного логического тома, только выглядещий в расшифрованном виде, после того как его открыли. Он отличается именем, которое вы задали в коммандной строке. Его можно смонтировать как если бы это был loop-device. Если его закрыть — он исчезает, остаётся имя, отображающее исходный шифрованный логический том.
шифровать можно и физические тома, тогда не будет видно сколько внутри находится логических томов.
1) Используйте LUKS, если не уверены в том, что делаете. Простой криптформат более низкоуровневый и требует ввода множества параметров. Кроме того, в LUKS предусмотрены множественные слоты ключей для шифровки главного мастер-ключа, "размазанное" хранение битов ключа для более безопасного удаления, лучше предусмотрена сама процедура удаления и другие опции безопасности.
2) Использование файлов в качестве контейнеров вместо использования разделов возможно, но менее безопасно. У нас об этом написано в FAQ[link6] в разделе "криптография: практика".
3) Если есть доступ на этот раздел какая разница откуда его монтировать?
1) Нужно ли писать специальные скрипты размонтирования криптованных разделов, созданных по методу, предложенному SATtva, в уже функционирующей системе?
2) Если у меня в линуксе смонтирован файл криптоконтейнера, и я не выполнив umount – cryptsetup luksClose – losetup -d начну делать shutdown, это чем-то грозит целостности ФС и файлов в этом устройстве?
Нет, при условии что ошибок в ФС и ядре нет. Система сама корректно размонтирует разделы при перезагрузке.
Т.е. портить незакрытые криптоконтейнеры, созданные FreeOTFE под виндами, особенность г-новенды?!
unknown, кстати я попробовал натравить cryptsetup luksDump на файл криптоконтейнера, и он меня послал, написав что не найдено признаков LUKS-формата.
Соответственно, когда я его инициализировал через luksOpen в loop-девайсом, и натравил на loop-девайс, тогда luksDump сказал мне, что да, это лукс.
Соответственно, получается что враг чтобы проверить должен все инициализирует luksOpen, который потребует пароля, который он не знает, и только потом проверять luksDump.
А поскольку не зная пароля он не сможет инициализировать, как он узнает, контейнер это или нет?
Вот, я ему расширение MP3 дал, так гном вообще его воспринимает как звуковой файл, тока воспроизводить не хочет :)
Так это может быть поврежденный звуковой файл просто, или я в чем-то неправ?
Это просто файл с расширением mp3. У реального mp3 должны быть уйма метаданных, а у сжатого звука — вполне определённая структура. Это ж как надо было повредить файл, чтобы не осталось ни того, ни другого?
Не, вру, luksDump надо натправливать на инициализированный с файлом losetup устройство loop, тогда он кажет, есть или нет формат лукс.
Паролем не надо открывать.
Но не на сам файл, поэтому гипотетически можно конечно написать скрипт, который будет инициализировать устройства и потом проверять есть ли лукс-формат или нет.
Но вопрос, а что делать потом с этим? Только для того, чтобы пытать потом владельца, совать ему во всякие интересные отверстия паяльники, чтобы он открыл контейнер?
Достаточно искать строку LUKS в первых байтах бинарника.
Оупенсорс позволяет полностью автоматизировать эту работу. Можно так:
Вот такая программа, брут-форс подборка паролей :)
А мужики-то не знают![link7]
Прошу прощения за тупость. Какой командной можно определить какое устройство /dev/loopX используется для данного контейнера?
Для инициализации криптоконтейнеров юзаю такой пользовательский скриптец (на основе того, что в начале топика рекомендовал SATtva):
Теперь хочу сделать скрипт, который одной командой его бы отмонтировал-разынициализировал:
А вот как написать последнюю строчку – тупости не хватает :)
– а вот какую команду туда вписать, туплю.
Мне в своё время было лень разбираться, возможно ли это, поэтому просто пишу соответствия между /dev/loop/* и /dev/mapper/* в текстовый файлик в tmpfs, который и парсится скриптом при размонтировании.
SATtva, начал по твоей инструкции перекриптовывать некриптованные разделы под действующей системой, благо диск у меня полтерабайта и позволяет и половина свободная.
Не подскажешь, а можно потом размер раздела увеличить? Вот у меня хомяк 350 ГБ, из них половина свободна.
Я отрезаю половину хомяка, создаю криптованный раздел, бросаю туда файлы с некриптованного, а потом я смогу увеличить размер криптованного раздела? И как?
Что-то мне в душе подсказывает, что если я просто изменю размер раздела с помощью gparted или fdisk'ом, то я не смогу его открыть... Или я неправ?
И еще такой вопрос. В твоей инструкции предлагается создать временный криптованный раздел, туда скопировать, потом на месте некриптованного создать криптованный и скопировать обратно.
А какой в этом практический смысл? Может тогда уже сразу скопировать в криптованный и монтировать его, а некриптованный грохнуть?
Только при использовании LVM.
Смысл только в экономии дискового пространства (я свои манипуляции проводил на ноутбуке с не очень большим диском). Если места дофига, то можно туда-сюда не таскать, конечно.
То есть, без LVM никак? Кроме как копировать на съемные носители и оттуда возвращать на место?
P. S. А физический раздел на котором установлено LVM можно увеличивать без ущерба для LVM и с увеличением пространства, используемого LVM, или никак?
P. P. S. Я изначально сдуру установил без LVM и без шифрованного LVM, теперь мучаюсь...
В Debian у меня по дефолту пустая директория /dm, есть файл /etc/crypttub.
Как я понимаю, править надо именно его, для настроек монтирования.
Файл такого формата (сейчас он пустой):
У САТтвыв мануале предусмотрено указание target и source. Как я понимаю, key file нужен когда будет использоваться keyfile, если же только парольная фраза – тогда оставлять пустым, или указывать нуль?
И что касается options, что там указывать?
Повкуривал man crypttab, остались кое-какие вопросы (и появились новые):
1) Вроде с keyfile'ом разобрался, если его нет, надо писать none, в options если LUKS-формат, надо указать как-минимум luks.
А какие опции еще (по практике) нужно или желательно там указать?
2) Что касается target, в мане написано такое:
Вроде понятно... и непонятно. Сейчас когда монтирую руками в /dev/mapper возникает устройство после команды cryptsetup luksOpen /dev/sdaX cryptpart с названием, заданным в последнем слове (в данном случае будет /dev/mapper/sryptpart).
После выполнения команды cryptsetup luksClose /dev/mapper/sryptpart это устройство удаляется.
Каким обрзаом оно должно быть создано? Надо чтоли какой-то скрипт в /etc/init.d для его создания положить?
3) В /etc/fstab все-таки что указывать, /dev/sdaX или /dev/mapper/cryptpart? Сначала crypttab читается чтоли при загрузке, а потом fstab?
Второе.
Да.
Замечательно все получилось, это я сдруру неправильно перевел "will be created at /dev/mapper/target by cryptsetup" не как "будут созданы", а как "надо создать" (типа "you should need".
Так что сейчас буду все остальное криптовать. Враг не пройдет!!!
Однако при загрузке я получается в любом случае должен ее монтировать, даже если не хочу в данном случае? Я пробовал после предложения ввести пароль дать команду Crtl-C, система не реагирует никак.
По умолчанию загрузочный скрипт настроен так, что после трёх неправильных попыток ввода пароля и соотвествующих пауз, загрузка продолжается с монтированием других доступных файловых систем по порядку.
Если вас это раздражает, можете вообще удалить строку из crypttab и монтировать вручную через две команды
Или можете поставить утилиту pmount, она позволяет монтировать в том числе и LUKS-шифрованные устройства в одну команду и даже без рутовых прав (можно создать список прав доступа пользователям на монтирование).
1) Если я не ввожу пароль в указанное гуевое окошко, а делаю что-то типа флешке, сразу после этого флешка автомонтируется hal'ом в /media/disk-X. Причем монитируется не с устройства /dev/mapper/flesh, которое создается указанной командой и присутствует в системе, а с какого-то устройства /dev/dm-1:
Что это за устройство такое и насколько безопасно такое монтирование критоустройства? (При том, что LUKS-партиция открывалась родным cryptsetup)
Кстати сказать, когда также руками монтируется криптованный раздел с HDD, hal не может его автосмонтировать, появляется окошко наутилуса где сказано, что смонитровать не удалось (mount ессно монтирует).
2)
В man'е pmount написано, что утилита только для съемных устройств. При этом не хочет даже монтировать флешки из файлов LUKS-девайсов:
В соответствии с требованиями man'а pmount'а, юзер включен в группу plugdev.
Попробуйте исключить из fstab и включить в белый список.
Про hal, монтирование с GUI и наутилус может кто-то другой подскажет, могу только посоветовать попробовать всё это отключить и попробовать решить проблему без них — возможно эти лишние для шифрования навороты вносят свои собственные глюки.
При монтировании криптораздела получается такой вывод :
Что за муйня и как лечить?!
При монтировании криптораздела получаю такой вывод об ошибках:
То есть опять, помимо устройств в /dev/mapper, еще и устройство /dev/dm-X. Что это за устройство?
У вас Intel-процессор без встроенного криптоускорителя.
Купить новый Intel-процессор, если хотите снизить наугрузку на процессор при шифровании скорее всего с 1% (на одно ядро) до 0.001%, если вы не обрабатываете гигабитные потоки шифрованных данных.
Всё нормально открылось без использования криптоускорителя.
Это так называемый прямой путь к устройствам логических томов. В некоторых коммандах (например по удалению томов или изменению их размера) нужно указывать именно этот путь. А в /dev вообще много интересного. Есть пути для устройства по UID и по заводским серийным номерам (для монтирования флэшек удобно)
То есть, если мне на ноуте надо монтировать крипторазделы – ничего страшного нет, что нет криптоускорителя? Он криптоустойчивость не повышает? Только ускоряет обработку процессором шифрованной информации?
А где можно по устройствам /dev почитать что-нибудь интересное и достаточно полное?
Делает AES более стойким что-ли? ;-))) Ну может против каких-то аппаратных или тайминг-атак, но не заморачивайтесь — шифрование винчестера на ноуте — это не тот случай. Как-то люди десятилетиями обходились без криптоускорителей и ничего. Их внедрили только в самые недавние версии процов.
В исходниках ядра, по-любому ;-)
Есть принципиальная разница с точки зрения безопасности, если монтируешь крипторазделы из консоли и из эмулятора терминала под иксами? Насколько первое может быть безопаснее второго и стоит ли заморачиваться по этому поводу?
Насколько я понял из манов и статей в инете, имеется возможность закриптовать linux-swap.
SatTVA тут помниться не раз высказывался вообще против свопа (учитывая что в настоящее время обычно достаточно RAM).
В связи с этим такой вопрос, если я закриптую своп, смогу ли я безопасно гибернироваться на этот криптованный своп? Или не получиться корректно загрузить систему с образа системы на таком свопе?
Сугубо теоретически – безопаснее, но если уже словил троян, то это не спасёт. Не стоит заморачиваться.
Если использовать шифрование поверх LVM, то если шифровать персонально логический том swap одноразовым ключём из /dev/urandom, то гибернация невозможна.
Если шифровать физический том, на котором находятся нешифрованные нужные логические тома для системы, включая отдельный раздел swap, то тогда будет работать нормально.
Уважаемый unknown, я юзаю ленни с ядром 30кой с бэкпортов. Под стандартным ядром, 26-м, я обнаружил, при открытии лукс-раздела указанное сообщение об ошибке не появляется. М.б. в процессоре есть криптоускоритель, просто новые версии ядра недокручены?
Какой флаг должен указывать на его наличие в /proc/cpuinfo?
У меня там такие:
В обычной версии Lenny скорее всего вообще нет этого криптомодуля, наберите под разными ядрами:
Или если ядро сами компилите — посмотрите в config, можно ли включить сборку этого модуля.
Обратил внимание что файлы LUKS-криптоконтейнеров, несмотря на создание, удаление и изменение файлов и директорий в этих криптоконтейнерах, сораняют одни и те же реквизиты времени их изменения по времени их создания; это нормально?
И просто тупое копирование такого файла приводит ли к созданию точной копии содержимого криптоконтейнера (если эту копию файла открывать через cryptsetup) или же нет? Т.е. достаточно для бэкапа просто такой файл скопировать или забэкапить с другими файлами в ФС, или надо обязательно его инициализировать, подмонтировать и делать бэкап уже со смонтированной на его основе ФС?
Всё так, но на всякий случай:
FAQ: Криптоконтейнеры и защита диска: Очень удобно создавать криптоконтейнер в виде файла, ведь это даёт возможность легко делать резервные копии на различных носителях, просто скопировав этот файл. Также его легко отправить на сервер для пересылки или хранения. Почему однако не рекомендуется делать копии контейнеров таким образом?[link8]
1. unknown, при загрузке под 30-м ядром после ввода пароля выдает следующую строку (к сожалению, раньше не успевал записать – а потом почему-то в логах ядра не находил):
Это как раз говорит о том, что процессор не поддерживает данную фичу? (нет соотв. девайса?).
Предложенные тобой команды под всеми установленными ядрами показали, что ничего этого нет.
2. Почему-то у меня после наверное 10-ти неправильных введений пароля на стадии загрузки не грузиться без раздела, а всякий раз возвращается к требованию luks-пароля.
unknown? Ну вообще стандартный дистр дебиана ленни, ничего там специально я не переконфигурировал в этом отношении
Может зависит от того как выбирали параметры инсталлятора, разбивали на разделы, например:
К сожалению, при инсталляции я еще был маленький и глупенький, поэтому не устновил сразу закриптованные разделы.
Сейчас у меня только один раздел для документов (даже не хомяк), типа /home1, который я создал впоследствии, с него ничего не грузиться.
P. S. Никак не заставлю себя найти время всю систему закриптовать. А переустанавливать совсем не хочется.