Distribuzioni basate su Debian:
Debian e Ubuntu forniscono uno script di memorizzazione nella cache delle password decrypt_keyctl con cryptsetup pacchetto.
decrypt_keyctl script fornisce la stessa password a più destinazioni LUKS crittografate, risparmiandoti di digitarla più volte. Può essere abilitato in crypttab con keyscript=decrypt_keyctl opzione. La stessa password viene utilizzata per le destinazioni che hanno lo stesso identificatore nel campo keyfile . All'avvio viene richiesta una volta la password per ogni identificatore.
Un esempio di crypttab :
<target> <source> <keyfile> <options>
part1_crypt /dev/disk/... crypt_disks luks,keyscript=decrypt_keyctl
part2_crypt /dev/disk/... crypt_disks luks,keyscript=decrypt_keyctl
Il decrypt_keyctl script dipende dal keyutils pacchetto (che è solo suggerito, e quindi non necessariamente installato).
Dopo aver aggiornato il tuo cryptab , dovrai anche aggiornare initramfs per applicare le modifiche. Usa update-initramfs -u .
Il file readme completo per decrypt_keyctl si trova in /usr/share/doc/cryptsetup/README.keyctl
Sfortunatamente, questo attualmente non funziona sui sistemi Debian che usano systemd init a causa di un bug (gli altri sistemi init non dovrebbero essere interessati). Con questo bug ti viene chiesta una seconda volta la password da systemd, rendendo impossibile lo sblocco da remoto tramite ssh. pagina man di crypttab Debian suggerisce come soluzione alternativa di utilizzare initramfs opzione per forzare l'elaborazione nella fase di avvio di initramfs. Quindi, per aggirare questo bug, un esempio per /etc/crypttab in Debian
<target> <source> <keyfile> <options>
part1_crypt /dev/disk/... crypt_disks luks,initramfs,keyscript=decrypt_keyctl
part2_crypt /dev/disk/... crypt_disks luks,initramfs,keyscript=decrypt_keyctl
Distribuzioni che non forniscono decrypt_keyctl sceneggiatura:
Se decrypt_keyctrl non è fornito dalla tua distribuzione, il dispositivo può essere sbloccato utilizzando un file chiave nel file system root crittografato. Questo quando il file system root può essere sbloccato e montato prima di qualsiasi altro dispositivo crittografato.
LUKS supporta più slot chiave. Ciò ti consente di sbloccare alternativamente il dispositivo utilizzando la password se il file della chiave non è disponibile/perso.
-
Genera la chiave con dati casuali e imposta le sue autorizzazioni su proprietario leggibile solo per evitare perdite. Tieni presente che il file della chiave deve trovarsi nella partizione root che viene sbloccata per prima.
dd if=/dev/urandom of=<path to key file> bs=1024 count=1 chmod u=rw,g=,o= <path to key file> -
Aggiungi la chiave al tuo dispositivo LUKS
cryptsetup luksAddKey <path to encrypted device> <path to key file> -
Configura crypttab per utilizzare il file chiave. La prima riga dovrebbe essere il dispositivo root, poiché i dispositivi vengono sbloccati nello stesso ordine elencato in crypttab . Usa percorsi assoluti per i file chiave.
<target> <source> <keyfile> <options> root_crypt /dev/disk/... none luks part1_crypt /dev/disk/... <path to key file> luks
Un'altra opzione è usare il /lib/cryptsetup/scripts/decrypt_derived script, che fa anche parte di cryptsetup in Debian/Ubuntu.
Invece di memorizzare nella cache la chiave, si utilizza la chiave del volume di un disco come password aggiuntiva per il secondo disco. Ciò richiede l'aggiunta di una seconda password al secondo (e terzo, ecc.) disco crittografato, ma LUKS lo supporta. Questa soluzione funziona quindi anche se i tuoi dischi crittografati multipli non utilizzano la stessa password.
Esempio per aggiungere la chiave da sda6crypt a sda5:
Aggiungi la chiave del volume di sda6crypt come password aggiuntiva per sda5:
mkfifo fifo
/lib/cryptsetup/scripts/decrypt_derived sda6crypt > fifo &
cryptsetup luksAddKey /dev/sda5 fifo
rm fifo
Configura sda5crypt in modo che venga sbloccato automaticamente in /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
Questo usa una pipe con nome (fifo ) per passare la chiave per evitare di dover archiviare la chiave del volume in un file temporaneo su disco.
Il keyscript l'opzione funziona solo se crypttab viene elaborato dagli strumenti cryptsetup originali di Debian, la reimplementazione di systemd attualmente non lo supporta. Se il tuo sistema usa systemd (che è la maggior parte dei sistemi), hai bisogno del initramfs opzione per forzare l'elaborazione in initrd da parte degli strumenti cryptsetup, prima dell'avvio di systemd.
Basato su https://unix.stackexchange.com/a/32551/50793
Ecco la mia soluzione alternativa su debian, dato il bug citato sopra da @sebasth.
La mia configurazione è leggermente diversa. Ho una partizione root crittografata e un mucchio di dischi raid. Per me, ho dovuto aggiungere un'opzione initramfs a 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
Questo dice a update-initramfs che voglio che queste voci crypttab siano montate in initramfs. Ho controllato il mio crypttab eseguendo
cryptdisks_start part1_crypt
cryptdisks_start part2_crypt
Nota che i miei dischi raid sono semplici dm-crypt. Ciò significava che non potevo usare il metodo del file di chiavi luks che aggira il bug del keyscript di systemd. Per il semplice dm-crypt, dovrei memorizzare la passphrase in testo normale.
Il pacchetto keyutils deve essere installato e i dischi cifrati devono essere montati prima di update-initramfs è eseguito; altrimenti genererà errori. Ho dovuto cercare le seguenti righe quando il mio initramfs è stato compilato:
update-initramfs -u -v | grep 'keyctl'
che mostrava i seguenti due file:
/bin/keyctl
cryptkeyctl
aggiunto a initramfs.
Infine, ho dovuto disabilitare systemd che gestisce il mio crypttab, per far fronte al bug a cui si fa riferimento sopra:systemd non supporta l'opzione keyscript in crypttab. Per questo, ho aggiunto l'opzione kernel
GRUB_CMDLINE_LINUX_DEFAULT="quiet luks.crypttab=no"
in /etc/default/grub ed eseguito update-grub . systemd ora ignora crypttab e tutte le partizioni crittografate vengono caricate in initramfs.
Poiché ho una partizione root crittografata, cryptroot non sembra memorizzare nella cache la mia chiave. Ciò significa che devo inserire la mia password due volte; uno per la partizione root e una per il mio array raid.