Korzystanie z jednego hasła do odblokowywania wielu zaszyfrowanych dysków podczas rozruchu

Mój komputer ma dysk SSD, na którym zainstalowałem system oraz dysk twardy, którego używam jako miejsca do przechowywania dużych i / lub rzadko używanych plików. Oba są zaszyfrowane, ale zdecydowałem się użyć dla nich tego samego hasła. /Dysk SSD jest zamontowany w, a HDD w /usr/hdd(każdy z użytkowników ma na nim katalog i może dowiązać symbolicznie, jak chce z katalogu domowego).

Po uruchomieniu systemu natychmiast prosi o podanie hasła do dysku SSD, a zaledwie kilka sekund później o hasło do dysku twardego (jest automatycznie montowane). Biorąc pod uwagę, że oba hasła są takie same, czy istnieje sposób, aby skonfigurować system tak, aby pytał tylko raz?

Dystrybucje oparte na Debianie:

Debian i Ubuntu dostarczają skrypt buforujący hasło decrypt_keyctl z pakietem cryptsetup .

Skrypt decrypt_keyctl zapewnia to samo hasło do wielu zaszyfrowanych celów LUKS, dzięki czemu nie musisz wpisywać go wiele razy. Można ją włączyć w opcji crypttab z keyscript=decrypt_keyctlopcją. To samo hasło jest używane dla celów, które mają ten sam identyfikator w polu pliku klucza . Podczas uruchamiania hasło dla każdego identyfikatora jest zadawane raz.

Przykładowa karta kryptograficzna :

<target>      <source>         <keyfile>      <options>
part1_crypt   /dev/disk/...    crypt_disks    luks,keyscript=decrypt_keyctl
part2_crypt   /dev/disk/...    crypt_disks    luks,keyscript=decrypt_keyctl

Po zaktualizowaniu cryptabu musisz także zaktualizować initramfs, aby zastosować zmiany. Zastosowanie update-initramfs -u.

Pełny plik readme dla decrypt_keyctl znajduje się w /usr/share/doc/cryptsetup/README.keyctl

Niestety, obecnie nie działa to w systemach Debian korzystających z systemd init ze względu na błąd (nie powinno to wpływać na inne systemy init). Debianowa strona podręcznika crypttab sugeruje jako obejście, aby użyć initramfsopcji wymuszenia przetwarzania na etapie bootowania initramfs.

Dystrybucje, które nie zapewniają skryptu decrypt_keyctl :

Jeśli Twoja dystrybucja nie udostępnia narzędzia decrypt_keyctrl , urządzenie można odblokować za pomocą pliku klucza w zaszyfrowanym systemie plików root. Dzieje się tak, gdy główny system plików można odblokować i zamontować przed innymi zaszyfrowanymi urządzeniami.

LUKS obsługuje wiele miejsc na klucze. Umożliwia to alternatywne odblokowanie urządzenia za pomocą hasła, jeśli plik klucza jest niedostępny / utracony.

1. Wygeneruj klucz z losowymi danymi i ustaw uprawnienia dla właściciela tylko do odczytu, aby uniknąć wycieku. Pamiętaj, że plik klucza musi znajdować się na partycji głównej, która jest najpierw odblokowana.

   dd if=/dev/urandom of=<path to key file> bs=1024 count=1
   chmod u=rw,g=,o= <path to key file>
   

2. Dodaj klucz do swojego urządzenia LUKS

   cryptsetup luksAddKey <path to encrypted device> <path to key file>
   

3. Skonfiguruj crypttab, aby używał pliku klucza. Pierwszą linią powinno być urządzenie root, ponieważ urządzenia są odblokowane w takiej samej kolejności, jak podano w crypttab . Użyj ścieżek bezwzględnych dla plików kluczowych.

   <target>      <source>         <keyfile>                  <options>
   root_crypt    /dev/disk/...    none                       luks
   part1_crypt   /dev/disk/...    <path to key file>         luks
   

Oto moje obejście dotyczące Debiana, biorąc pod uwagę błąd wymieniony powyżej przez @sebasth.

Moja konfiguracja jest nieco inna. Mam zaszyfrowaną partycję root i kilka dysków RAID. Dla mnie musiałem dodać opcję initramfs do crypttab:

<target>      <source>         <keyfile>      <options>
part1_crypt   /dev/disk/...    crypt_disks    plain,cipher=aes-xts-plain64,keyscript=decrypt_keyctl,initramfs
part2_crypt   /dev/disk/...    crypt_disks    plain,cipher=aes-xts-plain64,keyscript=decrypt_keyctl,initramfs

Mówi to update-initramfs, że chcę mieć te wpisy crypttab zamontowane w initramfs. Sprawdziłem moją kryptografię, uruchamiając

cryptdisks_start part1_crypt
cryptdisks_start part2_crypt

Zauważ, że moje dyski rajdowe są zwykłymi kryptami dm-crypt. Oznaczało to, że nie mogłem użyć metody pliku kluczy Luks, która działa wokół błędu skryptu systemd. W przypadku zwykłej krypty dm musiałbym przechowywać hasło w postaci zwykłego tekstu.

Zaszyfrowane dyski muszą zostać zamontowane przed update-initramfsuruchomieniem; w przeciwnym razie spowoduje to błędy. Musiałem poszukać następujących linii, kiedy moje initramfs zostało zbudowane:

update-initramfs -k -u -v | grep 'keyctl'

który pokazał następujące dwa pliki:

/bin/keyctl
cryptkeyctl

dodawane do initramfs.

Wreszcie musiałem wyłączyć systemd obsługujący moją kryptografię, aby poradzić sobie z błędem, o którym mowa powyżej: systemd nie obsługuje opcji skryptu w crypttabie. W tym celu dodałem opcję jądra

GRUB_CMDLINE_LINUX_DEFAULT="quiet luks.crypttab=no"     

do / etc / default / grub i uruchomiłem update-grub. systemd teraz ignoruje crypttab, a wszystkie zaszyfrowane partycje są ładowane do initramfs.

Ponieważ mam zaszyfrowaną partycję root, cryptroot nie wydaje się buforować mojego klucza. Oznacza to, że muszę dwukrotnie wpisać hasło; jeden dla partycji root i raz dla mojej tablicy RAID.

Inną opcją jest użycie /lib/cryptsetup/scripts/decrypt_derivedskryptu, który jest również częścią cryptsetup w Debian / Ubuntu.

Zamiast buforować klucz, używasz klucza woluminu na jednym dysku jako dodatkowego hasła do drugiego dysku. Wymaga to dodania drugiego hasła do drugiego (i trzeciego itd.) Zaszyfrowanego dysku, ale LUKS to obsługuje. To rozwiązanie działa zatem również wtedy, gdy wiele zaszyfrowanych dysków nie używa tego samego hasła.

Przykład dodania klucza z sda6crypt do sda5:

Dodaj klucz woluminu sda6crypt jako dodatkowe hasło do sda5:

mkfifo fifo
/lib/cryptsetup/scripts/decrypt_derived sda6crypt > fifo &
cryptsetup luksAddKey /dev/sda5 fifo
rm fifo

Sda5crypt skonfiguruj tak, aby był automatycznie odblokowywany /etc/crypttab

ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab

Używa nazwanego potoku ( fifo) do przekazania klucza, aby uniknąć konieczności przechowywania klucza woluminu w pliku tymczasowym na dysku.

Ta keyscriptopcja działa tylko wtedy, gdycrypttab są przetwarzane przez oryginalnych narzędzi cryptsetup Debiana, tym Systemd reimplementacja obecnie nie obsługuje go. Jeśli twój system używa systemd (czyli większości systemów), potrzebujesz initramfsopcji wymuszenia przetwarzania w initrd przez narzędzia cryptsetup, zanim systemd się uruchomi.

Na podstawie /unix//a/32551/50793