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

23

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?

linux disk-encryption cryptsetup doublep
la source
Vous pouvez éventuellement écrire un expectscript ou similaire qui sera appelé pour monter les disques au lieu de le faire par le système. Au lieu de cela, le système appelle le script qui demande le mot de passe, le stocke et le fournit à chacune des opérations de montage.
h3rrmiller
Si je comprends bien votre idée, elle ne peut pas être appliquée au SSD, car c'est de là que le système démarre. Mais cela devient inutile, car il me faudrait encore taper la phrase secrète pour le disque dur séparément. Ou pas?
doublep
Vous pouvez utiliser /etc/crypttab pour déverrouiller le deuxième lecteur .
jasonwryan
1
@jasonwryan si cela peut être étendu à une réponse, alors ... les réponses doivent être publiées sous forme de réponses, pas de commentaires.
derobert
1
@derobert parfois, les gens n'ont pas le temps ou l'envie de rédiger une bonne réponse.
jasonwryan

Réponses:

24

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
sebasth
la source
Dès les premières lignes du fichier Lisez-moi, cela semble très prometteur, merci. Je vérifierai cela demain (je ne veux pas redémarrer maintenant).
doublep
Malheureusement, cela ne fonctionne pas (comme dans aucun changement). Voir mescrypttab (je n'ai pas touché UUID=créé par l'installateur du système, je suppose que cela ne devrait pas avoir d'importance) et les entrées résultantes dans/var/log/syslog . Les erreurs sont en quelque sorte compréhensibles, mais je ne sais pas quoi faire à leur sujet. Le fichier /lib/cryptsetup/scripts/decrypt_keyctlexiste, donc je ne sais pas pourquoi il se plaint d'une option inconnue. Je n'ai également aucune idée de ce qu'il faut spécifier comme fichier de clés, je ne vois aucune explication nulle part ...
doublep
Avez-vous vérifié que decrypt_keyctl est inclus dans initramfs? Vérifiez-le en utilisant l'option verbose lors de la mise à jour de l'image:, update-initramfs -u -k $(uname -r) -vil devrait sortir Adding binary /lib/cryptsetup/scripts/decrypt_keyctl.
sebasth
1
Pour voir ce que contient initramfs:lsinitramfs /boot/initrd.img-$(uname -r)
sebasth
3
Euh, désolé, maintenant que j'ai payé plus d' attention à ce que update-initramfsdit, j'ai remarqué ceci: E: /usr/share/initramfs-tools/hooks/cryptkeyctl failed with return 1.. Après un peu de recherche sur Google, j'ai découvert que j'avais probablement besoin d'un keyutilspackage (vraiment pas installé). Maintenant update-initramfsréussit et lsinitramfsmentionne decrypt_keytls. Mettra à jour après le prochain démarrage (probablement demain).
doublep
3

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.

user128063
la source
1

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

JanKanis
la source
Je dois dire que c'est une belle solution A fonctionné dès le départ sans hoquet sur debian 10 buster!
Janus