LUKS keycript étant ignoré… demande un mot de passe

Permettez-moi de commencer en disant que je ne suis pas nouveau sur LUKS. J'ai configuré LUKS avec des scripts de touches à plusieurs reprises avec et sans LVM. Je ne sais pas vraiment ce qui se passe ici. J'ai un système qui a une seule partition cryptée. Mon trajet est organisé comme suit:

# lsblk

NOM MAJ: MIN RM SIZE RO TYPE MOUNTPOINT
disque sda ​​8: 0 0 128G 0  
└─sda1 8: 1 0 128G 0 partie  
  ├─vg0-root 253: 1 0 20G 0 lvm /
  ├─vg0-secure 253: 6 0 100M 0 lvm   
  │ └─secure 253: 7 0 98M 0 crypt / root / secure
  └─vg0-swap 253: 4 0 1G 0 lvm [SWAP]

Mon /etc/crypttabfichier ressemble à ceci

# L'UUID n'est pas requis ici car le chemin vers le LV ne changera pas
sécurisé / dev / vg0 / sécurisé aucun luks, keyscript = / lib / cryptsetup / scripts / insecure

Mon /lib/cryptsetup/scripts/insecurefichier 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 -uun certain nombre de fois après avoir configuré crypttab et mis en place mon fichier de clés.

Pour 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à.

Au redémarrage, le système voit l'enregistrement à partir de crypttab et demande un mot de passe (qui dans mon cas n'existe pas réellement car la seule clé est un fichier de clés plein de bits aléatoires) plutôt que d'utiliser le script de clé pour déverrouiller la partition LUKS. J'ai essayé de retirer LUKS du LVM et de le mettre sur sda2, et les résultats étaient les mêmes. Je sais également que le script de clé fonctionne parce qu'il 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 déjà utilisé des scripts de touches sans aucun problème. La seule différence était que, dans le passé, ma partition / était toujours cryptée. Si quelqu'un peut faire la lumière, je l'apprécierais. Je veux seulement une très petite partition cryptée parce que je prévois de cloner ce système, et je ne veux pas le cloner avec la partition / cryptée entière.

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 inconnue / etc / crypttab rencontrée 'keyscript = / lib / cryptsetup / scripts / insecure', ignorée.

Juste pour les coups de pied, j'ai essayé de supprimer l'option de script de clé et d'utiliser un fichier de clés, et tout cela a juste fonctionné! En fait, j'ai essayé d'autres options comme le décalage de fichier de clés, et elles fonctionnent aussi. Par conséquent, le problème se situe quelque part avec l'option keyscript. Quelqu'un sait-il pourquoi?

Essayez l'option "initramfs" dans votre / etc / crypttab (selon /unix//a/447676/356711 ). Votre /etc/crypttabressemblerait 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 votre fs racine peut se trouver 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 n'est pas dans un LVM. " Heureusement, il semble qu'une solution de contournement soit fournie.

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 ce qui suit /etc/crypttabfait la magie du déchiffrement avec un script (!) 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_cryptavec le script de clé fourni fonctionne sans l'option initramfs (car il contient la racine fs et est donc "automatiquement" pris en compte dans la phase de démarrage initramfs). md1_cryptn'a été décrypté que pendant la phase de démarrage initramfs (et donc avec le script de clé selon l'entrée crypttab) après avoir ajouté l'option initramfs. Le décryptage ultérieur de md1_crypt pendant la phase de démarrage de systemd ne fonctionne pas avec un script de clé donné dans crypttab car le "systemd cryptsetup" ne prend pas en charge l'option keyscript, voir https://github.com/systemd/systemd/pull/3007 .