Permettez-moi de commencer par dire que je ne suis pas nouveau chez LUKS. J'ai souvent configuré LUKS avec des scripts de clavier avec et sans LVM. Je ne suis pas sûr de ce qui se passe réellement ici. J'ai un système qui a une seule partition cryptée. Mon entraînement est organisé comme suit:
# lsblk NOM MAJ: MIN RM SIZE RO TYPE MOUNTPOINT sda 8: 0 0 128G 0 disque Dasda1 8: 1 0 128G 0 partie ├─vg0-root 253: 1 0 20G 0 lvm / Vg0-secure 253: 6 0 100M 0 lvm Ec └─secure 253: 7 0 98M 0 crypt /root/secure Vg0-swap 253: 4 0 1G 0 lvm [SWAP]
Mon fichier /etc/crypttab
ressemble à ceci
# L'UUID n'est pas requis ici car le chemin d'accès au LV ne changera pas Secure/dev/vg0/secure aucuns clés, keyscript =/lib/cryptsetup/scripts/insecure
Mon fichier /lib/cryptsetup/scripts/insecure
est exécutable et ressemble à ceci
#!/bin/sh
# My actual file looks somewhat different because it dumps the key file with dd.
# This accomplishes virtually the same thing though.
echo -n "my-encryption-password"
J'ai exécuté update-initramfs -k all -u
plusieurs fois après avoir configuré crypttab et mis mon fichier de clés à la place.
Autant que je sache, mon fichier de script n'est même pas copié dans le fichier initrd.img. Maintenant que j'y pense, je ne pense pas qu'il serait copié dans le fichier initrd.img car la partition racine n'est pas chiffrée et le fichier de script devrait être facilement accessible à partir de là.
Lors du redémarrage, le système voit l'enregistrement de crypttab et demande un mot de passe (qui n'existe pas dans mon cas car la seule clé est un fichier de clés contenant des bits aléatoires) plutôt que d'utiliser le script pour ouvrir la partition LUKS. J'ai essayé de sortir LUKS du LVM et de le mettre sur sda2, et les résultats étaient les mêmes. Je sais aussi que le script fonctionne parce que cryptsetup luksOpen /dev/vg0/secure secure -d - <<< "$(/lib/cryptsetup/scripts/insecure)"
fonctionne comme un charme et déchiffre ma partition LUKS.
J'ai essayé cela dans Ubuntu 16.04.2 et Ubuntu Mate 16.04.2 avec les mêmes résultats. J'ai utilisé des scripts de clés auparavant sans aucun problème. La seule différence était que, dans le passé, ma partition/était toujours chiffrée. Si quelqu'un peut nous éclairer, je l'apprécierais. Je veux seulement une très petite partition chiffrée parce que je prévois de cloner ce système et que je ne veux pas le cloner avec la partition/partition entière chiffrée.
MISE À JOUR 2017-04-26
En fouillant dans les journaux, j'ai trouvé une ligne avec l'erreur suivante qui n'a aucun sens. Depuis quand 'keyscript =/path/to/script' est-il une option inconnue pour crypttab?
... systemd-cryptsetup [737]: Option/etc/crypttab inconnue rencontrée 'keyscript =/lib/cryptsetup/scripts/insecure', ignorant.
Juste pour le plaisir, j'ai essayé de supprimer l'option keyscript et d'utiliser un fichier de clés, et tout cela a fonctionné! En fait, j'ai essayé d'autres options telles que keyfile-offset, et elles fonctionnent aussi. Par conséquent, le problème réside quelque part avec l'option keyscript. Est-ce que quelqu'un a une idée pourquoi?
Essayez l’option "initramfs" dans votre/etc/crypttab (selon https://unix.stackexchange.com/a/447676/356711 ). Votre /etc/crypttab
ressemblerait alors à ceci:
# UUID is not required here since the path to the LV won't change
secure /dev/vg0/secure none luks,keyscript=/lib/cryptsetup/scripts/insecure,initramfs
Veuillez noter que le problème peut être que votre fs racine se trouve dans un conteneur LVM. Ce problème est également mentionné dans l'article lié ci-dessus: ", mais cela ne fonctionne actuellement (de manière fiable) que si le périphérique racine ne se trouve pas dans un LVM. " Heureusement, il semble qu'une solution de contournement est fourni.
Mon système ressemble à ceci:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
└─sda1 8:1 0 931.5G 0 part
└─md1 9:1 0 931.4G 0 raid1
└─md1_crypt 253:3 0 931.4G 0 crypt
└─raid_crypt_vg-data_lv 253:4 0 931.4G 0 lvm /raid
sdb 8:16 0 931.5G 0 disk
└─sdb1 8:17 0 931.5G 0 part
└─md1 9:1 0 931.4G 0 raid1
└─md1_crypt 253:3 0 931.4G 0 crypt
└─raid_crypt_vg-data_lv 253:4 0 931.4G 0 lvm /raid
sdc 8:32 0 465.8G 0 disk
├─sdc1 8:33 0 953M 0 part /boot
└─sdc2 8:34 0 464.8G 0 part
└─sdc2_crypt 253:0 0 464.8G 0 crypt
├─system_crypt_vg-data_lv 253:1 0 447G 0 lvm /
└─system_crypt_vg-swap_lv 253:2 0 17.8G 0 lvm [SWAP]
... et le /etc/crypttab
suivant fait la magie de décryptage avec un script de clé (!) dans Ubuntu 18.04.2 LTS:
$ cat /etc/crypttab
# <target name> <source device> <key file> <options>
sdc2_crypt UUID=[...] none luks,discard,keyscript=/etc/decryptkeydevice/decryptkeydevice_keyscript.sh
md1_crypt /dev/md1 none luks,discard,keyscript=/etc/decryptkeydevice/decryptkeydevice_keyscript.sh,initramfs
Notez que le déchiffrement de sdc2_crypt
avec le keyscript fourni fonctionne sans l'option initramfs (car elle contient la racine fs et est donc "automatiquement" prise en compte dans initramfs phase de démarrage). md1_crypt
n'a déjà été décrypté que pendant la phase de démarrage d'initramfs (et donc avec le keyscript conformément à l'entrée de la table de chiffrement) après avoir ajouté l'option initramfs. Le déchiffrement ultérieur de md1_crypt lors de la phase de démarrage de systemd ne fonctionne pas avec un script défini dans crypttab car "systemd cryptsetup" ne prend pas en charge l'option keyscript, voir https://github.com/systemd/systemd/pull/3007 .