Utilisation d'une phrase de passe unique pour déverrouiller plusieurs disques chiffrés au démarrage

Ma machine a un SSD, où j'ai installé le système et un disque dur, que j'utilise comme stockage pour les fichiers volumineux et / ou rarement utilisés. Les deux sont cryptés, mais j'ai choisi d'utiliser la même phrase secrète pour eux. SSD est monté sur /et HDD sur /usr/hdd(les utilisateurs individuels ont chacun un répertoire et peuvent créer des liens symboliques comme ils le souhaitent depuis le répertoire personnel).

Lorsque le système est démarré, il demande immédiatement une phrase secrète pour le SSD, et quelques secondes plus tard pour celle pour le disque dur (il est monté automatiquement). Étant donné que les deux mots de passe sont identiques, existe-t-il un moyen de configurer le système pour qu'il ne demande qu'une seule fois?

Distributions basées sur Debian:

Debian et Ubuntu livrent un script de mise en cache des mots de passe decrypt_keyctl avec le paquet cryptsetup .

Le script decrypt_keyctl fournit le même mot de passe à plusieurs cibles LUKS chiffrées, vous évitant de le taper plusieurs fois. Il peut être activé dans crypttab avec keyscript=decrypt_keyctloption. Le même mot de passe est utilisé pour les cibles qui ont le même identifiant dans le champ du fichier de clés . Au démarrage, un mot de passe pour chaque identifiant est demandé une fois.

Un exemple de 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

Après avoir mis à jour votre cryptab , vous devrez également mettre à jour initramfs pour appliquer les modifications. Utilisez update-initramfs -u.

Le fichier Lisezmoi complet pour decrypt_keyctl se trouve dans /usr/share/doc/cryptsetup/README.keyctl

Malheureusement, cela ne fonctionne pas actuellement sur les systèmes Debian utilisant systemd init en raison d' un bogue (les autres systèmes init ne devraient pas être affectés). La page de manuel de Debian crypttab propose une solution de contournement pour utiliser l' initramfsoption pour forcer le traitement à l'étape initramfs du démarrage.

Distributions qui ne fournissent pas de script decrypt_keyctl :

Si decrypt_keyctrl n'est pas fourni par votre distribution, l'appareil peut être déverrouillé à l'aide d'un fichier de clés dans le système de fichiers racine chiffré. Cela lorsque le système de fichiers racine peut être déverrouillé et monté avant de tout autre appareil crypté.

LUKS prend en charge plusieurs emplacements de clé. Cela vous permet également de déverrouiller l'appareil à l'aide d'un mot de passe si le fichier de clé n'est pas disponible / perdu.

1. Générez la clé avec des données aléatoires et définissez ses autorisations en lecture seule par le propriétaire pour éviter de la divulguer. Notez que le fichier de clé doit être sur la partition racine qui est déverrouillée en premier.

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

2. Ajoutez la clé à votre appareil LUKS

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

3. Configurez crypttab pour utiliser le fichier de clés. La première ligne doit être le périphérique racine, car les périphériques sont déverrouillés dans le même ordre que celui répertorié dans crypttab . Utilisez des chemins absolus pour les fichiers clés.

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

Voici ma solution de contournement sur Debian, étant donné le bogue référencé ci-dessus par @sebasth.

Ma configuration est légèrement différente. J'ai une partition racine chiffrée et un tas de disques de raid. Pour moi, j'ai dû ajouter une option initramfs à la 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

Cela indique à update-initramfs que je veux que ces entrées crypttab soient montées dans les initramfs. J'ai vérifié mon crypttab en exécutant

cryptdisks_start part1_crypt
cryptdisks_start part2_crypt

Notez que mes disques de raid sont des dm-crypt simples. Cela signifiait que je ne pouvais pas utiliser la méthode luks keyfile qui contourne le bogue keycript de systemd. Pour dm-crypt simple, je devrais stocker la phrase secrète en texte clair.

Les disques chiffrés doivent être montés avant d' update-initramfsêtre exécutés; sinon, cela générera des erreurs. J'ai dû chercher les lignes suivantes lors de la construction de mes initramfs:

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

qui montrait les deux fichiers suivants:

/bin/keyctl
cryptkeyctl

étant ajouté aux initramfs.

Enfin, j'ai dû désactiver systemd pour gérer mon crypttab, afin de faire face au bogue référencé ci-dessus: systemd ne prend pas en charge l'option keyscript dans crypttab. Pour cela, j'ai ajouté l'option noyau

GRUB_CMDLINE_LINUX_DEFAULT="quiet luks.crypttab=no"     

dans / etc / default / grub et a couru update-grub. systemd ignore maintenant crypttab, et toutes les partitions chiffrées sont chargées dans les initramfs.

Parce que j'ai une partition racine chiffrée, cryptroot ne semble pas mettre en cache ma clé. Cela signifie que je dois saisir mon mot de passe deux fois; un pour la partition racine et une fois pour ma baie de raid.

Une autre option consiste à utiliser le /lib/cryptsetup/scripts/decrypt_derivedscript, qui fait également partie de cryptsetup dans Debian / Ubuntu.

Au lieu de mettre la clé en cache, vous utilisez la clé de volume d'un disque comme mot de passe supplémentaire pour le deuxième disque. Cela nécessite l'ajout d'un deuxième mot de passe au deuxième (et troisième, etc.) disque crypté, mais LUKS le prend en charge. Cette solution fonctionne donc également si vos multiples disques chiffrés n'utilisent pas le même mot de passe.

Exemple pour ajouter la clé de sda6crypt à sda5:

Ajoutez la clé de volume de sda6crypt comme mot de passe supplémentaire pour sda5:

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

Configurez sda5crypt pour qu'il soit déverrouillé automatiquement dans /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

Cela utilise un tube nommé ( fifo) pour passer la clé pour éviter d'avoir à stocker la clé de volume dans un fichier temporaire sur le disque.

L' keyscriptoption ne fonctionne que si elle crypttabest traitée par les outils cryptsetup d'origine de Debian, la réimplémentation systemd ne la prend pas actuellement en charge. Si votre système utilise systemd (qui est la plupart des systèmes), vous avez besoin de l' initramfsoption pour forcer le traitement à se produire dans l'initrd par les outils cryptsetup, avant le démarrage de systemd.

Basé sur /unix//a/32551/50793