Utilizzo di un'unica passphrase per sbloccare più dischi crittografati all'avvio

La mia macchina ha un SSD, in cui ho installato il sistema e un HDD, che utilizzo come memoria per file di grandi dimensioni e / o usati raramente. Entrambi sono crittografati, ma ho scelto di usare la stessa passphrase per loro. SSD è montato su /e HDD su /usr/hdd(i singoli utenti hanno ciascuno una directory su di esso e possono collegarsi come preferiscono dalla directory home).

Quando il sistema viene avviato, richiede immediatamente la passphrase per l'SSD, e solo un paio di secondi dopo quello per l'HDD (è montato automaticamente). Dato che entrambe le passphrase sono uguali, esiste un modo per configurare il sistema per chiedere una sola volta?

linux disk-encryption cryptsetup

— doublep
fonte

Potresti scrivere uno expectscript o simile che viene chiamato per montare i dischi invece di farlo fare al sistema. Invece, il sistema chiamerebbe lo script che richiederebbe la password, la memorizzerebbe e la fornirebbe a ciascuna delle operazioni di montaggio.

— h3rrmiller,

Se capisco correttamente la tua idea, non può essere applicata all'SSD, poiché è da lì che viene avviato il sistema. Ma poi diventa inutile, poiché avrei ancora bisogno di digitare la passphrase per l'HDD separatamente. O no?

— doublep

È possibile utilizzare /etc/crypttab per sbloccare la seconda unità .

— Jasonwryan,

@jasonwryan se questo può essere esteso a una risposta, allora ... le risposte devono essere pubblicate come risposte, non come commenti.

— derobert,

@derobert a volte le persone non hanno il tempo o l'inclinazione di scrivere una buona risposta.

— Jasonwryan,

Risposte:

Distribuzioni basate su Debian:

Debian e Ubuntu forniscono uno script di memorizzazione nella cache decrypt_keyctl con pacchetto cryptsetup .

decrypt_keyctl script fornisce la stessa password a più destinazioni LUKS crittografate, evitando di digitarla più volte. Può essere abilitato in crypttab con keyscript=decrypt_keyctlopzione. La stessa password viene utilizzata per destinazioni che hanno lo stesso identificatore nel campo del file di chiavi . All'avvio viene richiesta una volta la password per ciascun 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

Dopo aver aggiornato il tuo cryptab , dovrai anche aggiornare initramfs per applicare le modifiche. Usa update-initramfs -u.

Il file Leggimi completo per decrypt_keyctl si trova in /usr/share/doc/cryptsetup/README.keyctl

Sfortunatamente, questo attualmente non funziona su sistemi Debian che usano systemd init a causa di un bug (altri sistemi init non dovrebbero essere interessati). La pagina man di Debian crypttab suggerisce come soluzione alternativa l'uso initramfsdell'opzione per forzare l'elaborazione nella fase di avvio di initramfs.

Distribuzioni che non forniscono lo script decrypt_keyctl :

Se decrypt_keyctrl non è fornito dalla tua distribuzione, il dispositivo può essere sbloccato utilizzando un file di chiavi nel file system radice crittografato. Questo quando il file system di root può essere sbloccato e montato prima di qualsiasi altro dispositivo crittografato.

LUKS supporta più slot di tasti. Ciò consente di sbloccare il dispositivo in alternativa utilizzando la password se il file chiave non è disponibile / perso.

Generare la chiave con dati casuali e impostare le autorizzazioni su leggibile dal proprietario solo per evitare la perdita. Si noti che il file chiave deve trovarsi sulla partizione root che viene prima sbloccata.
```
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 usare il file chiave. La prima riga dovrebbe essere il dispositivo radice, poiché i dispositivi sono 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
```

— sebasth
fonte

Fin dalle prime righe del readme sembra molto promettente, grazie. Lo controllerò domani (non voglio riavviare ora).

— doublep

Sfortunatamente, non funziona (come in nessun cambiamento). Vedi il miocrypttab (non ho toccato UUID=creato dall'installatore del sistema, immagino che non dovrebbe importare) e le voci risultanti in/var/log/syslog . Gli errori sono in qualche modo comprensibili, ma non ho idea di cosa fare al riguardo. Il file /lib/cryptsetup/scripts/decrypt_keyctlesiste, quindi non so perché si lamenta di un'opzione sconosciuta. Inoltre non ho idea di cosa specificare come file di chiavi, non vedo alcuna spiegazione da nessuna parte ...

— doublep

Hai verificato che decrypt_keyctl viene incluso in initramfs? Controllalo usando l'opzione dettagliata quando aggiorni l'immagine update-initramfs -u -k $(uname -r) -v:, dovrebbe essere generato Adding binary /lib/cryptsetup/scripts/decrypt_keyctl.

— sebasth,

Per vedere cosa contiene initramfs:lsinitramfs /boot/initrd.img-$(uname -r)

— sebasth,

Uh, mi dispiace, ora che ho pagato più attenzione a quello che update-initramfsha detto, ho notato questo: E: /usr/share/initramfs-tools/hooks/cryptkeyctl failed with return 1.. Dopo un po 'di ricerche su Google, ho scoperto che probabilmente avevo bisogno di un keyutilspacchetto (davvero non era installato). Ora ha update-initramfssuccesso e lsinitramfsmenziona decrypt_keytls. Si aggiornerà dopo il prossimo avvio (probabilmente domani).

— doublep,

Ecco la mia soluzione alternativa su debian, dato il bug sopra citato da @sebasth.

La mia configurazione è leggermente diversa. Ho una partizione root crittografata e un sacco di dischi raid. Per me, ho dovuto aggiungere un'opzione initramfs al 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 avere queste voci crypttab montate in initramfs. Ho controllato il mio crypttab correndo

cryptdisks_start part1_crypt
cryptdisks_start part2_crypt

Nota che i miei dischi raid sono semplicemente dm-crypt. Ciò significava che non potevo usare il metodo luks keyfile che funziona attorno al bug di systemd keyscript. Per il semplice dm-crypt, dovrei archiviare la passphrase in testo semplice.

I dischi crittografati devono essere montati prima di update-initramfsessere eseguiti; altrimenti genererà errori. Ho dovuto cercare le seguenti righe quando è stato creato il mio initramfs:

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

che mostrava i seguenti due file:

/bin/keyctl
cryptkeyctl

viene aggiunto a initramfs.

Infine, ho dovuto disabilitare systemd gestendo il mio crypttab, per gestire il bug di cui sopra: systemd non supporta l'opzione keyscript in crypttab. Per questo, ho aggiunto l'opzione del kernel

GRUB_CMDLINE_LINUX_DEFAULT="quiet luks.crypttab=no"

su / 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. Questo significa che devo inserire la mia password due volte; uno per la partizione di root e una volta per il mio array raid.

— user128063
fonte

Un'altra opzione è quella di utilizzare il /lib/cryptsetup/scripts/decrypt_derived script, che fa anche parte del 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 quindi funziona anche se i tuoi dischi multipli crittografati non usano 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

Configurare sda5crypt per essere 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 utilizza una pipe denominata (fifo ) per passare la chiave per evitare di dover memorizzare la chiave del volume in un file temporaneo sul disco.

L' keyscriptopzione funziona solo se crypttabviene elaborata dagli strumenti di cryptsetup originali di Debian, la reimplementazione di systemd non la supporta attualmente. Se il tuo sistema utilizza systemd (che è la maggior parte dei sistemi), hai bisogno diinitramfs opzione per forzare l'elaborazione in initrd da parte degli strumenti di crittografia, prima dell'avvio di systemd.

Basato su /unix//a/32551/50793

— JanKanis
fonte

Devo dire che questa è una bella soluzione Ha funzionato fin dall'inizio senza alcun singhiozzo su Debian 10 Buster!

— Janus,