Как определить LVM-over-LUKS или LUKS-over-LVM


14

Я недавно установил Fedora 20. Я не помню, какие именно параметры я выбрал для шифрования диска / LVM во время установки. Он установлен нормально, и я могу войти и т. Д. Вот ситуация у меня:

Я загрузился с LiveCD и попробовал следующее: (Я установил Fedora20 в раздел / dev / sda3 ').

  1. Если я запускаю, cryptsetup open /dev/sda3 fedoя получаю сообщение о том, что это не устройство LUKS.
  2. cryptsetup luksDump /dev/sda3Я запускаю, я получаю сообщение о том, что это не устройство LUKS
  3. Если я запускаю cryptsetup open --type plain /dev/sda3 fedo, он запрашивает пароль и открывает устройство нормально.

Итак, очевидно, что это зашифрованный текст (без заголовка LUKS) раздел.

Теперь, когда я пытаюсь бежать mount /dev/mapper/fedo /mnt/fedora, это говорит unknown crypto_LUKS filesystem.

У меня есть LVM поверх него, так что , я могу бежать pvdisplay, vgdisplay, lvdisplayи он показывает информацию. У меня VG называется fedoraи два LV, а именно 00 для раздела подкачки и 01 для / раздела.

Теперь, если я делаю a, cryptsetup luksDump /dev/fedora/01я вижу заголовки LUKS и т. Д. И я могу смонтировать, запустив mount /dev/fedora/00 /mnt/fedora, без запроса пароля.

Итак, есть ли у меня зашифрованный раздел LUKS-over-LVM-over- (обычный текст)?

Вот мой вывод lsblk:

# lsblk
НАИМЕНОВАНИЕ MAJ: MIN RM РАЗМЕР RO ТИП MOUNTPOINT
сда 8:00 37,3 г 0 диск
| -sda3 8:30 17,4 G 0 часть
  | -fedora-00 253: 0 2.5G 0 lvm
  | | -luks-XXXXX 253: 30 0 2.5G 0 склеп [SWAP]
  | -fedora-01 253: 1 0 15G 0 lvm
    | -luks-XXXXX 253: 2 0 15G 0 склеп /

Итак, вопрос в том, как определить, есть ли у меня LVM-over-LUKS или LUKS-over-LVM , или какая-то другая их комбинация ( LUKS over LVM поверх LUKS и т. Д.)? Чтобы прояснить мой вопрос, я знаю, что у меня есть LVM и LUKS, я хочу выяснить их порядок.

Ответы:


14

cryptsetup luksDump /dev/fedora/01показывает, что логический том LVM является зашифрованным томом LUKS. Вывод pvsили pvdisplayпокажет, что раздел /dev/sda3является физическим томом. Таким образом, у вас есть LUKS над LVM. На более низком уровне у вас есть раздел LVM на ПК.

Выходные данные lsblkподтверждают это: sdaэто диск, sda3раздел (который содержит физический том LVM) fedora-00и fedora-01логические тома, и каждый логический том содержит зашифрованный том LUKS.


Прекрасный ответ и подтверждает мои тесты. Я не могу голосовать за ваш ответ, так как я новичок здесь и у меня недостаточно высокая репутация :-(
NotSuperMan

8

Очень странно иметь ЛУКС в простом склепе. Зачем шифровать дважды?

Как только ваши файловые системы смонтированы, lsblkвы увидите, что к чему.

NAME                         MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                            8:0    0  59.6G  0 disk  
└─sda1                         8:1    0  59.6G  0 part  
  └─md0                        9:0    0  59.6G  0 raid1 
    └─luksSSD1               253:9    0  59.6G  0 crypt 
      ├─SSD-home             253:0    0    36G  0 lvm   /home
      └─SSD-root             253:10   0    16G  0 lvm   /

Это LVM (/ home и / с типом lvm) на LUKS (тип crypt, luksSSD1) на RAID1 (md0, тип raid1) на обычном разделе (sda1) на диске sda.


Да, это странно. Я добавил вывод 'lsblk' в свой вопрос.
NotSuperMan

@NotSuperMan: ну, это выглядит хорошо. диск, раздел, lvm, и каждый LV зашифрован. Это обычная настройка. Ваше описание звучало как-то иначе. Я думаю, что ваша ошибка заключалась в использовании cryptsetup --plain на sda3; sda3 - это устройство LVM, а не крипта.
frostschutz

Спасибо за вашу помощь. Но без cryptsetup --type plain я не смог бы даже смонтировать раздел. Так что, мне было не понятно. Может быть, вместо того, чтобы монтировать раздел сначала, я должен монтировать LV напрямую, используя LUKS-UUID? (Я сделаю это). Когда я бегу, fdisk -l /dev/sdaон говорит, /dev/sda3что Id - это 8e, а Type - это Linux LVM.
NotSuperMan

OK. Вместо того, чтобы пытаться «открыть cryptsetup» раздел сначала, я просто использовал cryptsetup open /dev/disk/by-uuid/UUID-of-LV SomeNameкоманду, чтобы открыть LV непосредственно, и он запросил пароль и т. Д., И впоследствии, я смог нормально смонтировать подключенное устройство. Это многое объясняет для меня. Я думаю, что ключ - это порядок типов «crypt» и «lvm» в выходных данных lsblkкоманды. Итак, я думаю, что моя установка - LUKS-over-LVM . И из результатов, которые вы показали, я пришел к выводу, что ваша установка LVM-over-LUKS . Итак, я пришел к выводу, что я не должен 'cryptsetup открывать' раздел Linux LVM.
NotSuperMan

Ваши комментарии помогли мне очистить мое понимание. К сожалению, я не могу проголосовать за ваш ответ, так как я здесь новичок и у меня недостаточно высокая «репутация» :-( и поэтому stackexchange не позволяет мне голосовать за ваш ответ.
NotSuperMan

3

Вы можете увидеть, что у вас есть так:

$ sudo blkid | grep crypto_LUKS
/dev/mapper/fedora-home: UUID="XXXXXXXXXXXXXXXXX" TYPE="crypto_LUKS" 

Это логический том LVM с крипто-лукой на нем. Когда я монтирую этот том, он монтируется под Fedora 20 следующим образом:

$ mount | grep home
/dev/mapper/luks-XXXXX on /home type ext4 (rw,relatime,seclabel,data=ordered)

Если вы сделали стандартную установку, у вас будет то же самое.

Расшифровка вручную

Я считаю, что вы можете сделать следующее, если вы хотите сделать вещи вручную. Сначала, чтобы увидеть, если что-то УДАЧИ или нет:

$ sudo cryptsetup isLuks /dev/mapper/fedora-home
$ echo $?
0

$ sudo cryptsetup isLuks /dev/mapper/fedora-root 
$ echo $?
1

ПРИМЕЧАНИЕ: ноль означает, что это LUKS, а 1 означает, что это не так.

Итак, чтобы расшифровать это:

$ sudo cryptsetup luksOpen /dev/mapper/fedora-home crypthome

ПРИМЕЧАНИЕ. Для расшифровки раздела необходимо ввести кодовую фразу. Не стесняйтесь менять название сопоставления crypthomeна любое другое. Сопоставленный раздел теперь доступен, /dev/mapper/crypthomeно не смонтирован. Последний шаг - создание точки монтирования и монтирование сопоставленного раздела:

Монтаж вручную

$ sudo -Es
$ mkdir /mnt/crypthome && mount /dev/mapper/crypthome /mnt/crypthome

Какие зашифрованные разделы у меня есть?

Вы можете проверить в файле, /etc/crypttabчтобы увидеть, какие LUKS вы также настроили.

$ more /etc/crypttab  
luks-XXXXXXXX UUID=XXXXXXXX none 

Сбросить устройство

Вы также можете использовать luksDumpтак:

$ sudo cryptsetup luksDump /dev/mapper/fedora-home
LUKS header information for /dev/mapper/fedora-home

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        512
MK digest:      XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 
MK salt:        XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 
                XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 
MK iterations:  50625
UUID:           XXXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX

Key Slot 0: ENABLED
    Iterations:             202852
    Salt:                   XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 
                            XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 
    Key material offset:    8
    AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Если это не устройство LUKS, об этом будет сообщено так:

$ sudo cryptsetup luksDump /dev/mapper/fedora-root 
Device /dev/mapper/fedora-root is not a valid LUKS device.

Ссылки


1

Я думаю, ключом к выяснению, является ли это LVM-over-LUKS или наоборот, является порядок TYPE crypt и lvm в выходных данных команды. Исходя из этого, я пришел к выводу, что моя установка - LUKS-over-LVM . Для вывода для установки типа LVM-over-LUKS, посмотрите на вывод, показанный @frostschultz ниже.lsblklsblk

В моем случае, поскольку / dev / sda3 является системным разделом «Linux LVM» (идентификатор раздела 8e), я думаю, что вместо того, чтобы пытаться cryptsetup open --type plain /dev/sda3 SomeNameсначала, мне следовало сопоставить LVM напрямую, выполнив cryptsetup open /dev/disk/by-uuid/UUID-of-LV SomeNameкоманду, чтобы открыть LV непосредственно. Я попробовал это, и это работает, как я ожидал.

Спасибо всем, кто помог мне понять это.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.