Jak rozpoznać LVM-over-LUKS lub LUKS-over-LVM


14

Niedawno zainstalowałem Fedorę 20. Nie pamiętam, jakie dokładnie opcje wybrałem do szyfrowania dysku / LVM podczas instalacji. Zainstalował się dobrze i mogę się zalogować itp. Oto moja sytuacja:

Uruchomiłem się z LiveCD i próbowałem: (Zainstalowałem Fedorę na partycji / dev / sda3 ').

  1. Po uruchomieniu cryptsetup open /dev/sda3 fedopojawia się błąd informujący, że nie jest to urządzenie LUKS.
  2. II uruchomienie cryptsetup luksDump /dev/sda3Występuje błąd informujący, że nie jest to urządzenie LUKS
  3. Jeśli uruchomię cryptsetup open --type plain /dev/sda3 fedo, monituje o hasło i otwiera urządzenie w porządku.

Oczywiście jest to partycja zaszyfrowana zwykłym tekstem (bez nagłówka LUKS).

Teraz, kiedy próbuję uciec mount /dev/mapper/fedo /mnt/fedora, mówi unknown crypto_LUKS filesystem.

Muszę LVM na wierzchu, więc mogę uruchomić pvdisplay, vgdisplay, lvdisplaya to pokazuje informacje. Mam VG o nazwie fedorai dwa LV, mianowicie 00 dla partycji wymiany i 01 dla partycji /.

Teraz, jeśli to zrobię cryptsetup luksDump /dev/fedora/01, mogę zobaczyć nagłówki LUKS itp. I mogę zamontować, uruchamiając mount /dev/fedora/00 /mnt/fedora, bez monitu o podanie hasła.

Czy mam partycję zaszyfrowaną LUKS-over-LVM-over- (zwykły tekst)?

Oto mój dorobek lsblk:

# lsblk
NAZWA MAJ: MIN RM ROZMIAR RO TYPE MOUNTPOINT
sda 8: 0 0 37,3G 0 dysk
| -sda3 8: 3 0 17,4G 0 część
  | -fedora-00 253: 0 0 2,5 G 0 lvm
  | | -luks-XXXXX 253: 3 0 2,5G 0 krypt [SWAP]
  | -fedora-01 253: 1 0 15G 0 lvm
    | -luks-XXXXX 253: 2 0 15G 0 krypt /

Pytanie brzmi: jak dowiedzieć się, czy mam LVM-over-LUKS lub LUKS-over-LVM , czy też inną ich kombinację ( LUKS ponad LVM ponad LUKS itp.)? Aby wyjaśnić moje pytanie, wiem, że mam LVM i LUKS, chcę ustalić ich kolejność.

Odpowiedzi:


14

cryptsetup luksDump /dev/fedora/01pokazuje wolumin logiczny LVM jako wolumin zaszyfrowany przez LUKS. Dane wyjściowe pvslub pvdisplaypokazałyby, że partycja /dev/sda3jest woluminem fizycznym. Zatem masz LUKS nad LVM. Na niższym poziomie masz LVM na partycji PC.

Dane wyjściowe lsblkpotwierdzają to: sdajest dyskiem, sda3jest partycją (która zawiera wolumin fizyczny LVM) fedora-00i fedora-01jest woluminami logicznymi, a każdy wolumin logiczny zawiera wolumin zaszyfrowany LUKS.


Doskonała odpowiedź i potwierdza moje testy. Nie mogę głosować na twoją odpowiedź, ponieważ jestem tutaj nowicjuszem i nie mam wystarczająco wysokiej reputacji :-(
— NotSuperMan

8

Dziwnie jest mieć LUKS w zwykłej krypcie. Po co szyfrować dwukrotnie?

Po zamontowaniu systemów plików lsblkpokaże ci, co jest.

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   /

Jest to LVM (/ home i / z typem lvm) na LUKS (typ crypt, luksSSD1) na RAID1 (md0, typ raid1) na regularnej partycji (sda1) na dysku sda.


Tak, to dziwne. Dodałem wynik „lsblk” do mojego pytania.
— NotSuperMan

@NotSuperMan: cóż, wygląda dobrze. dysk, partycja, lvm, a każda LV jest szyfrowana. To powszechna konfiguracja. Twój opis brzmiał jakoś inaczej. Myślę, że twoim błędem było użycie cryptsetup --plain na sda3; sda3 to urządzenie LVM, a nie szyfrowanie.
— frostschutz

Dzięki za pomoc. Ale bez zwykłego szyfrowania nie mógłbym nawet zamontować partycji. Nie było to dla mnie jasne. Może zamiast montowania partycji najpierw powinienem zamontować LV za pomocą LUKS-UUID bezpośrednio? (Dam temu szansę) Kiedy prowadzę fdisk -l /dev/sda, mówi, że /dev/sda3Id to 8e, a Type to Linux LVM.
— NotSuperMan

DOBRZE. Zamiast próbować najpierw „otworzyć cryptsetup” partycję, po prostu użyłem cryptsetup open /dev/disk/by-uuid/UUID-of-LV SomeNamepolecenia, aby bezpośrednio otworzyć LV i poprosiłem o passowrd itp., A następnie udało mi się dobrze zamontować zmapowane urządzenie. To mi wiele wyjaśnia. Myślę, że kluczem jest kolejność „crypt” i „lvm” TYPE w danych wyjściowych lsblkpolecenia. Myślę więc, że moja konfiguracja to LUKS-over-LVM . I z wyników, które pokazałeś, dochodzę do wniosku, że twoja konfiguracja LVM-over-LUKS . Stwierdzam więc, że nie powinienem „cryptsetup otwierać” partycji „Linux LVM”.
— NotSuperMan,

Twoje komentarze pomogły mi wyjaśnić moje zrozumienie. Niestety nie jestem w stanie głosować na twoją odpowiedź, ponieważ jestem tutaj nowicjuszem i nie mam wystarczająco wysokiej „reputacji” :-( a więc
— wymiana stosów

3

Możesz zobaczyć, co lubisz, więc:

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

To wolumin logiczny LVM z krypto LUKS. Kiedy podłączam ten wolumin, jest on montowany w następujący sposób w Fedorze 20:

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

Jeśli wykonałeś standardową instalację, będziesz mieć tę samą rzecz.

Ręczne deszyfrowanie

Uważam, że możesz wykonać następujące czynności, jeśli chcesz robić rzeczy ręcznie. Najpierw sprawdź, czy coś jest LUKS, czy nie:

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

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

UWAGA: zero oznacza, że ​​jest to LUKS, a 1 oznacza, że ​​nie.

Więc aby go odszyfrować:

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

UWAGA: Musisz wprowadzić hasło, aby odszyfrować partycję. Zmień nazwę mapowania crypthomena dowolną. Zmapowana partycja jest teraz dostępna, /dev/mapper/crypthomeale nie jest zamontowana. Ostatnim krokiem jest utworzenie punktu montowania i zamontowanie zmapowanej partycji:

Montaż ręczny

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

Jakie mam zaszyfrowane partycje?

Możesz sprawdzić w pliku, /etc/crypttababy zobaczyć, jaki LUKS również skonfigurowałeś.

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

Zrzut urządzenia

Możesz również użyć luksDumptak:

$ 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

Jeśli nie jest to urządzenie LUKS, zostanie zgłoszone w następujący sposób:

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

Bibliografia


1

Myślę, że kluczem do dowiedzieć się, czy jest to LVM-over-LUKS, lub na odwrót, to kolejność krypt i LVM typów w wyjściu lsblkpolecenia. Na podstawie tego rozumowania stwierdzam, że moja konfiguracja to LUKS-over-LVM . Aby uzyskać dane lsblkwyjściowe dla konfiguracji typu LVM-over-LUKS, spójrz na dane wyjściowe pokazane przez @frostschultz poniżej.

W moim przypadku, ponieważ / dev / sda3 jest partycją systemową „Linux LVM” (identyfikator partycji 8e), myślę, że zamiast próbować cryptsetup open --type plain /dev/sda3 SomeNamenajpierw, powinienem był mapować LVM bezpośrednio, uruchamiając cryptsetup open /dev/disk/by-uuid/UUID-of-LV SomeNamepolecenie, aby bezpośrednio otworzyć LV. Próbowałem tego i działa zgodnie z oczekiwaniami.

Dziękuję wszystkim, którzy przyczynili się do tego, aby pomóc mi to zrozumieć.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.