Il keycript LUKS viene ignorato ... richiede la password

Vorrei iniziare dicendo che non sono nuovo di LUKS. Ho installato LUKS con script di chiavi numerose volte con e senza LVM. Non sono sicuro di cosa stia succedendo qui. Ho un sistema che ha una singola partizione crittografata. Il mio disco è organizzato come segue:

# lsblk

NOME MAJ: TAGLIA MIN. RM TIPO MOUNTPOINT
sda 8: 0 0 128G 0 disco  
S─sda1 8: 1 0 128G 0 parte  
  ├─vg0-root 253: 1 0 20G 0 lvm /
  ├─vg0-secure 253: 6 0 100M 0 lvm   
  │ └─sicuro 253: 7 0 98M 0 crypt / root / secure
  └─vg0-swap 253: 4 0 1G 0 lvm [SWAP]

Il mio /etc/crypttabfile è simile a questo

# UUID non è richiesto qui poiché il percorso verso LV non cambierà
secure / dev / vg0 / secure none luks, keyscript = / lib / cryptsetup / scripts / insecure

Il mio /lib/cryptsetup/scripts/insecurefile è eseguibile e assomiglia a questo

#!/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"

Ho eseguito update-initramfs -k all -udiverse volte dopo aver configurato crypttab e messo in atto il mio file keycript.

Per quanto ne so, il mio file di script non viene nemmeno copiato nel file initrd.img. Ora che ci penso, non penso che verrebbe copiato nel file initrd.img poiché la partizione di root non è crittografata e il file di script dovrebbe essere facilmente accessibile da lì.

Al riavvio, il sistema vede il record da crypttab e chiede una password (che nel mio caso in realtà non esiste perché l'unica chiave è un file di chiavi pieno di bit casuali) piuttosto che usare lo script per sbloccare la partizione LUKS. Ho provato a togliere LUKS dall'LVM e metterlo su sda2, e i risultati sono stati gli stessi. So anche che il keycript funziona perché cryptsetup luksOpen /dev/vg0/secure secure -d - <<< "$(/lib/cryptsetup/scripts/insecure)"funziona come un incantesimo e decodifica la mia partizione LUKS.

Ho provato questo in Ubuntu 16.04.2 e Ubuntu Mate 16.04.2 con gli stessi risultati. Ho usato prima i keycript senza alcun problema. L'unica differenza era che, in passato, la mia / partizione era sempre crittografata. Se qualcuno può far luce, lo apprezzerei. Voglio solo una partizione crittografata molto piccola perché ho intenzione di clonare questo sistema e non voglio clonarlo con l'intera / partizione crittografata.

AGGIORNAMENTO 2017-04-26

Scorrendo i registri, ho trovato una riga con il seguente errore che non ha senso. Da quando 'keyscript = / path / to / script' è un'opzione sconosciuta per crypttab?

... systemd-cryptsetup [737]: ha riscontrato l'opzione sconosciuta / etc / crypttab 'keyscript = / lib / cryptsetup / scripts / insecure', ignorando.

Solo per i calci, ho provato a rimuovere l'opzione keyscript e usando un file di chiavi, e tutto ha funzionato! In effetti, ho provato altre opzioni come l'offset del file di chiavi e funzionano anche. Quindi, il problema risiede da qualche parte con l'opzione keyscript. Qualcuno ha idea del perché?

Prova l'opzione "initramfs" nel tuo / etc / crypttab (secondo https://unix.stackexchange.com/a/447676/356711 ). Il tuo /etc/crypttabsarebbe quindi simile a questo:

# 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

Si noti che potrebbe essere un problema il fatto che il root fs si trovi in ​​un contenitore LVM. Questo problema è anche menzionato nell'articolo collegato sopra: " Ma attualmente funziona (in modo affidabile) solo se il dispositivo radice non è in un LVM. " Fortunatamente, sembra che sia fornita una soluzione alternativa.

Il mio sistema è simile al seguente:

$ 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]

... e quanto segue /etc/crypttabfa la magia di decodifica con uno script (!) in 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

Si noti che la decrittazione di sdc2_cryptcon il keycript fornito funziona senza l'opzione initramfs (perché contiene il root fs ed è quindi "automaticamente" considerato nella fase di avvio di initramfs). md1_cryptè stato decifrato solo durante la fase di avvio di initramfs (e quindi con lo script in base alla voce crypttab) dopo aver aggiunto l'opzione initramfs. La decodifica successiva di md1_crypt durante la fase di avvio di systemd non funziona con un keycript fornito in crypttab perché "systemd cryptsetup" non supporta l'opzione keycript, consultare https://github.com/systemd/systemd/pull/3007 .