Ignorowany skrypt LUKS… pyta o hasło

Zacznę od stwierdzenia, że ​​nie jestem nowy w LUKS. Wiele razy konfigurowałem LUKS ze skryptami klawiszowymi z LVM i bez. Nie jestem jednak pewien, co się tutaj właściwie dzieje. Mam system z jedną zaszyfrowaną partycją. Mój dysk jest zorganizowany w następujący sposób:

# lsblk

NAZWA MAJ: MIN RM ROZMIAR RO TYPE MOUNTPOINT
sda 8: 0 0 128G 0 dysk  
Dasda1 8: 1 0 128G 0 część  
  Gvg0-root 253: 1 0 20G 0 lvm /
  ├─vg0-secure 253: 6 0 100M 0 lvm   
  25 ure zabezpieczyć 253: 7 0 98M 0 crypt / root / secure
  └─vg0-swap 253: 4 0 1G 0 lvm [SWAP]

Mój /etc/crypttabplik wygląda mniej więcej tak

# UUID nie jest tutaj wymagany, ponieważ ścieżka do LV nie zmieni się
bezpieczne / dev / vg0 / bezpieczne brak luks, keycript = / lib / cryptsetup / scripts / niepewne

Mój /lib/cryptsetup/scripts/insecureplik jest wykonywalny i wygląda mniej więcej tak

#!/bin/sh
# My actual file looks somewhat different because it dumps the key file with dd.
# This accomplishes virtually the same thing though.

echo -n "my-encryption-password"

Uruchomiłem update-initramfs -k all -uwiele razy po skonfigurowaniu crypttab i umieszczeniu mojego pliku kluczy.

O ile wiem, mój plik skryptu nawet nie jest kopiowany do pliku initrd.img. Teraz, gdy o tym myślę, nie sądzę, aby został skopiowany do pliku initrd.img, ponieważ partycja root nie jest zaszyfrowana, a plik skryptu powinien być łatwo dostępny z tego miejsca.

Po ponownym uruchomieniu system widzi rekord z crypttab i prosi o hasło (które w moim przypadku tak naprawdę nie istnieje, ponieważ jedynym kluczem jest plik kluczy pełen losowych bitów), zamiast używać klucza do odblokowania partycji LUKS. Próbowałem usunąć LUKS z LVM i umieścić go na sda2, a wyniki były takie same. Wiem też, że skrypt działa, ponieważ cryptsetup luksOpen /dev/vg0/secure secure -d - <<< "$(/lib/cryptsetup/scripts/insecure)"działa jak urok i odszyfrowuje moją partycję LUKS.

Próbowałem tego w Ubuntu 16.04.2 i Ubuntu Mate 16.04.2 z tymi samymi wynikami. Używałem wcześniej skryptów bez żadnych problemów. Jedyną różnicą było to, że w przeszłości moja partycja była zawsze szyfrowana. Jeśli ktoś mógłby rzucić trochę światła, byłbym wdzięczny. Chcę tylko bardzo małej zaszyfrowanej partycji, ponieważ planuję sklonować ten system i nie chcę go klonować z zaszyfrowaną całą partycją.

AKTUALIZACJA 26.04.2017

Podczas kopania dzienników znalazłem wiersz z następującym błędem, co nie ma sensu. Od kiedy „keycript = / path / to / script” jest nieznaną opcją dla crypttab?

... systemd-cryptsetup [737]: Napotkano nieznaną opcję / etc / crypttab „keycript = / lib / cryptsetup / scripts / niepewny”, ignorując.

Tylko dla kopnięć próbowałem usunąć opcję skryptu i użyć pliku klucza i wszystko działało! W rzeczywistości wypróbowałem inne opcje, takie jak przesunięcie pliku klucza, i one też działają. Stąd problem leży gdzieś w opcji skryptu. Czy ktoś ma pojęcie dlaczego?

Wypróbuj opcję „initramfs” w / etc / crypttab (zgodnie z https://unix.stackexchange.com/a/447676/356711 ). Twój /etc/crypttabwyglądałby wtedy tak:

# UUID is not required here since the path to the LV won't change
secure      /dev/vg0/secure       none      luks,keyscript=/lib/cryptsetup/scripts/insecure,initramfs

Pamiętaj, że może być problem z tym, że twój root fs znajduje się w kontenerze LVM. Ten problem jest również wspomniany w artykule z linkiem powyżej: „ Ale obecnie działa to (niezawodnie) tylko wtedy, gdy urządzenie root nie znajduje się w LVM. ” Na szczęście wydaje się, że zapewniono obejście tego problemu.

Mój system wygląda następująco:

$ lsblk
NAME                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                             8:0    0 931.5G  0 disk
└─sda1                          8:1    0 931.5G  0 part
  └─md1                         9:1    0 931.4G  0 raid1
    └─md1_crypt               253:3    0 931.4G  0 crypt
      └─raid_crypt_vg-data_lv 253:4    0 931.4G  0 lvm   /raid
sdb                             8:16   0 931.5G  0 disk
└─sdb1                          8:17   0 931.5G  0 part
  └─md1                         9:1    0 931.4G  0 raid1
    └─md1_crypt               253:3    0 931.4G  0 crypt
      └─raid_crypt_vg-data_lv 253:4    0 931.4G  0 lvm   /raid
sdc                             8:32   0 465.8G  0 disk
├─sdc1                          8:33   0   953M  0 part  /boot
└─sdc2                          8:34   0 464.8G  0 part
  └─sdc2_crypt                253:0    0 464.8G  0 crypt
    ├─system_crypt_vg-data_lv 253:1    0   447G  0 lvm   /
    └─system_crypt_vg-swap_lv 253:2    0  17.8G  0 lvm   [SWAP]

... a poniżej następuje /etc/crypttabmagia deszyfrowania za pomocą klawisza (!) w Ubuntu 18.04.2 LTS:

$ cat /etc/crypttab
# <target name> <source device>                           <key file> <options>
sdc2_crypt      UUID=[...]                                none       luks,discard,keyscript=/etc/decryptkeydevice/decryptkeydevice_keyscript.sh
md1_crypt       /dev/md1                                  none       luks,discard,keyscript=/etc/decryptkeydevice/decryptkeydevice_keyscript.sh,initramfs

Zauważ, że odszyfrowanie sdc2_cryptza pomocą dostarczonego skryptu działa bez opcji initramfs (ponieważ zawiera root fs i dlatego jest „automatycznie” uwzględniany w fazie uruchamiania initramfs). md1_cryptzostał odszyfrowany już podczas fazy rozruchu initramfs (a więc z użyciem klucza zgodnie z wpisem crypttab) po dodaniu opcji initramfs. Późniejsze odszyfrowanie md1_crypt podczas fazy rozruchu systemd nie działa z skryptem kluczowym podanym w crypttab, ponieważ „systemd cryptsetup” nie obsługuje skryptu opcji, patrz https://github.com/systemd/systemd/pull/3007 .