web-dev-qa-db-fra.com

LUKS keyscript ignoré ... demande le mot de passe

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?

10
b_laoshi

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 .

3
Thomas Popp