Distributions basées sur Debian :
Debian et Ubuntu livrent un script de mise en cache du mot de passe decrypt_keyctl avec cryptsetup paquet.
decrypt_keyctl Le script fournit le même mot de passe à plusieurs cibles LUKS chiffrées, ce qui vous évite de le saisir plusieurs fois. Il peut être activé dans crypttab avec keyscript=decrypt_keyctl option. Le même mot de passe est utilisé pour les cibles qui ont le même identifiant dans le champ keyfile . Au démarrage, le mot de passe pour chaque identifiant est demandé une fois.
Un exemple 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
Le decrypt_keyctl le script dépend du keyutils package (qui n'est que suggéré, et donc pas nécessairement installé).
Après avoir mis à jour votre cryptab , vous devrez également mettre à jour initramfs pour appliquer les modifications. Utilisez update-initramfs -u .
Le fichier readme 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 d'initialisation ne devraient pas être affectés). Avec ce bug on vous demande une deuxième fois le mot de passe par systemd, rendant impossible le déverrouillage à distance via ssh. Debian page de manuel de crypttab suggère comme solution de contournement d'utiliser initramfs option pour forcer le traitement à l'étape initramfs du démarrage. Donc pour contourner ce bug un exemple pour /etc/crypttab dans 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
Distributions qui ne fournissent pas decrypt_keyctl script :
Si decrypt_keyctrl n'est pas fourni par votre distribution, l'appareil peut être déverrouillé à l'aide d'un fichier clé dans le système de fichiers racine chiffré. Ceci lorsque le système de fichiers racine peut être déverrouillé et monté avant tout autre appareil chiffré.
LUKS prend en charge plusieurs emplacements de clé. Cela vous permet de déverrouiller alternativement l'appareil à l'aide d'un mot de passe si le fichier clé n'est pas disponible/perdu.
-
Générez la clé avec des données aléatoires et définissez ses autorisations sur propriétaire lisible uniquement pour éviter de la divulguer. Notez que le fichier 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> -
Ajoutez la clé à votre appareil LUKS
cryptsetup luksAddKey <path to encrypted device> <path to key file> -
Configurer crypttab pour utiliser le fichier clé. 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 indiqué 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
Une autre option consiste à utiliser le /lib/cryptsetup/scripts/decrypt_derived script, 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 d'ajouter un deuxième mot de passe au deuxième (et troisième, etc.) disque chiffré, mais LUKS le prend en charge. Cette solution fonctionne donc aussi 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
Ceci 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.
Le keyscript l'option ne fonctionne que si crypttab est traité par les outils cryptsetup originaux de Debian, la réimplémentation de systemd ne le prend pas actuellement en charge. Si votre système utilise systemd (qui est la plupart des systèmes), vous avez besoin du initramfs option pour forcer le traitement à se produire dans l'initrd par les outils cryptsetup, avant le démarrage de systemd.
Basé sur https://unix.stackexchange.com/a/32551/50793
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 cryptée et un tas de disques RAID. Pour moi, j'ai dû ajouter une option initramfs au 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 souhaite que ces entrées crypttab soient montées dans initramfs. J'ai vérifié mon crypttab en exécutant
cryptdisks_start part1_crypt
cryptdisks_start part2_crypt
Notez que mes disques RAID sont en clair dm-crypt. Cela signifiait que je ne pouvais pas utiliser la méthode luks keyfile qui contourne le bogue systemd keyscript. Pour plain dm-crypt, je devrais stocker la phrase secrète en clair.
Le package keyutils doit être installé et les disques chiffrés doivent être montés avant update-initramfs est exécuté; sinon il lancera des erreurs. J'ai dû rechercher les lignes suivantes lors de la construction de mon initramfs :
update-initramfs -u -v | grep 'keyctl'
qui affichait les deux fichiers suivants :
/bin/keyctl
cryptkeyctl
étant ajouté à l'initramfs.
Enfin, j'ai dû désactiver systemd gérant mon crypttab, pour faire face au bug référencé ci-dessus :systemd ne prend pas en charge l'option keyscript dans crypttab. Pour cela, j'ai ajouté l'option kernel
GRUB_CMDLINE_LINUX_DEFAULT="quiet luks.crypttab=no"
à /etc/default/grub et a exécuté update-grub . systemd ignore maintenant crypttab et toutes les partitions chiffrées sont chargées dans 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 mon tableau RAID.