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.