Cách xác định LVM-over-LUKS hoặc LUKS-over-LVM


13

Gần đây tôi đã cài đặt Fedora 20. Tôi không nhớ những tùy chọn chính xác nào tôi đã chọn để mã hóa đĩa / LVM trong khi cài đặt. Nó được cài đặt tốt và tôi có thể đăng nhập, vv Đây là tình huống tôi có:

Tôi đã khởi động với LiveCD và thử các cách sau: (Tôi đã cài đặt phân vùng Fedora20 đến / dev / sda3 ').

  1. Nếu tôi chạy, cryptsetup open /dev/sda3 fedotôi gặp lỗi khi nói đó không phải là thiết bị LUKS.
  2. cryptsetup luksDump /dev/sda3Tôi chạy tôi gặp lỗi khi nói nó không phải là thiết bị LUKS
  3. Nếu tôi chạy cryptsetup open --type plain /dev/sda3 fedo, nó sẽ nhắc mật khẩu và nó sẽ mở thiết bị.

Vì vậy, rõ ràng, đó là một phân vùng được mã hóa văn bản đơn giản (không có tiêu đề LUKS).

Bây giờ, khi tôi cố chạy mount /dev/mapper/fedo /mnt/fedora, nó nói unknown crypto_LUKS filesystem.

Tôi có LVM trên đầu trang của nó, vì vậy, tôi có thể chạy pvdisplay, vgdisplay, lvdisplayvà nó hiển thị thông tin. Tôi có một VG được gọi fedoravà hai LV, viz 00 cho phân vùng trao đổi và 01 cho / phân vùng.

Bây giờ, nếu tôi làm cryptsetup luksDump /dev/fedora/01tôi có thể thấy các tiêu đề LUKS, v.v. Và, tôi có thể gắn kết bằng cách chạy mount /dev/fedora/00 /mnt/fedora, không có dấu nhắc mật khẩu.

Vì vậy, tôi có phân vùng được mã hóa LUKS-over-LVM-over- (văn bản thuần túy) không?

Đây là đầu ra của tôi về lsblk:

# lsblk
TÊN MAJ: MIN RM KÍCH THƯỚC RO LOẠI MOUNTPOINT
sda 8: 0 0 37.3G 0 đĩa
| -sda3 8: 3 0 17.4G 0 phần
  | -fedora-00 253: 0 0 2.5G 0 lvm
  | | -luks-XXXXX 253: 3 0 2.5G 0 mật mã [SWAP]
  | -fedora-01 253: 1 0 15G 0 lvm
    | -luks-XXXXX 253: 2 0 15G 0 mật mã /

Vì vậy, câu hỏi là, làm thế nào để biết liệu tôi có LVM-over-LUKS hay LUKS-over-LVM , hoặc một số kết hợp khác của chúng ( LUKS trên LVM trên LUKS, v.v.)? Để làm cho câu hỏi của tôi rõ ràng, tôi biết tôi có LVM và LUKS, tôi muốn tìm ra thứ tự của chúng.

Câu trả lời:


14

cryptsetup luksDump /dev/fedora/01hiển thị âm lượng logic LVM là âm lượng được mã hóa LUKS. Đầu ra của pvshoặc pvdisplaysẽ hiển thị phân vùng /dev/sda3là một khối vật lý. Vì vậy, bạn có LUKS trên LVM. Ở cấp độ thấp hơn, bạn có LVM trên phân vùng PC.

Đầu ra của lsblkxác nhận điều này: sdalà một đĩa, sda3là một phân vùng (chứa một khối lượng vật lý LVM) fedora-00fedora-01là các khối logic và mỗi khối logic chứa một khối được mã hóa LUKS.


Câu trả lời hoàn hảo và xác nhận các bài kiểm tra của tôi. Tôi không thể bỏ phiếu cho câu trả lời của bạn mặc dù tôi là người mới ở đây và không có danh tiếng đủ cao :-(
NotSuperMan

8

Thật kỳ quặc khi có LUKS bên trong một mật mã đơn giản. Tại sao mã hóa hai lần?

Khi hệ thống tập tin của bạn được gắn kết, lsblksẽ cho bạn thấy những gì.

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   /

Đây là LVM (/ home và / với loại lvm) trên LUKS (loại mật mã, luksSSD1) trên RAID1 (md0, gõ raid1) trên phân vùng thông thường (sda1) trên sda đĩa.


Vâng, nó thật kỳ lạ. Tôi đã thêm đầu ra của 'lsblk' vào câu hỏi của mình.
NotSuperMan

@NotSuperMan: tốt, có vẻ tốt. đĩa, phân vùng, lvm và mỗi LV được mã hóa. Đây là một thiết lập phổ biến. Mô tả của bạn nghe có vẻ khác nhau. Tôi nghĩ rằng lỗi của bạn là sử dụng cryptsetup - hãy tìm trên sda3; sda3 là một thiết bị LVM, không phải mật mã.
frostschutz

Cảm ơn bạn đã giúp đỡ. Nhưng, không có cryptsetup --type plain, tôi thậm chí không thể gắn kết phân vùng. Vì vậy, nó không rõ ràng với tôi. Có thể thay vì gắn phân vùng trước, tôi có nên gắn LV bằng cách sử dụng LUKS-UUID trực tiếp không? (Tôi sẽ cho nó một phát) Khi tôi chạy, fdisk -l /dev/sdanó báo /dev/sda3là Id là 8e và Type là Linux LVM.
NotSuperMan

ĐỒNG Ý. Thay vì cố gắng 'cryptsetup mở' phân vùng trước, tôi chỉ sử dụng cryptsetup open /dev/disk/by-uuid/UUID-of-LV SomeNamelệnh để mở LV trực tiếp và nó đã yêu cầu passowrd, v.v., và sau đó, tôi đã có thể gắn thiết bị được ánh xạ tốt. Điều này giải thích rất nhiều cho tôi. Tôi nghĩ rằng khóa là thứ tự của các loại 'mật mã và' lvm 'trong đầu ra của lsblklệnh. Vì vậy, tôi nghĩ rằng thiết lập của tôi là LUKS-over-LVM . Và, từ đầu ra mà bạn đã hiển thị, tôi kết luận của bạn là một thiết lập LVM-over-LUKS . Vì vậy, tôi kết luận rằng tôi không nên 'mở cryptsetup' một phân vùng 'Linux LVM'.
NotSuperMan

Nhận xét của bạn đã giúp tôi làm rõ những hiểu biết của tôi. Thật không may, tôi không thể bỏ phiếu cho câu trả lời của bạn vì tôi là người mới ở đây và không có "tiếng tăm" đủ cao :-( và vì vậy, stackexchange không cho phép tôi bỏ phiếu cho câu trả lời của bạn.
NotSuperMan

3

Bạn có thể thấy những gì bạn thích như vậy:

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

Đó là khối lượng logic LVM với LUKS tiền điện tử trên đó. Khi tôi lắp âm lượng đó, nó sẽ được gắn như thế này trong Fedora 20:

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

Nếu bạn đã cài đặt tiêu chuẩn, bạn sẽ có điều tương tự.

Giải mã thủ công

Tôi tin rằng bạn có thể làm như sau nếu bạn muốn làm mọi thứ bằng tay. Đầu tiên để xem có gì đó là LUKS hay không:

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

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

LƯU Ý: Số không biểu thị rằng đó là LUKS, số 1 có nghĩa là không.

Vì vậy, sau đó để giải mã nó:

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

LƯU Ý: Bạn phải nhập cụm mật khẩu để giải mã phân vùng. Hãy thoải mái thay đổi tên ánh xạ crypthomethành bất cứ điều gì bạn muốn. Phân vùng được ánh xạ hiện có sẵn /dev/mapper/crypthomenhưng nó không được gắn kết. Bước cuối cùng là tạo một điểm gắn kết và để gắn kết phân vùng được ánh xạ:

Gắn thủ công

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

Tôi có những phân vùng được mã hóa nào?

Bạn có thể kiểm tra trong tệp /etc/crypttabđể xem LUKS nào bạn đã thiết lập.

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

Bán phá giá thiết bị

Bạn cũng có thể sử dụng luksDumpnhư vậy:

$ 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

Nếu đó không phải là thiết bị LUKS thì nó sẽ được báo cáo như vậy:

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

Người giới thiệu


1

Tôi nghĩ rằng chìa khóa để tìm hiểu xem đó có phải là LVM-over-LUKS hay ngược lại, là thứ tự của các LOẠI mã hóalvm trong đầu ra của lsblklệnh. Dựa trên lý do đó, tôi kết luận thiết lập của mình là LUKS-over-LVM . Để biết lsblkđầu ra cho loại thiết lập LVM-over-LUKS, hãy xem đầu ra được hiển thị bởi @frostschultz bên dưới.

Trong trường hợp của tôi, vì / dev / sda3 là phân vùng hệ thống "Linux LVM" (phân vùng Id 8e), tôi nghĩ thay vì cố gắng cryptsetup open --type plain /dev/sda3 SomeNametrước tiên, tôi nên ánh xạ LVM trực tiếp bằng cách chạy lệnh cryptsetup open /dev/disk/by-uuid/UUID-of-LV SomeNamelệnh để mở LV trực tiếp. Tôi đã thử điều này và nó hoạt động như tôi mong đợi.

Cảm ơn tất cả những người đã góp phần giúp tôi hiểu điều này.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.