Ajouter un 2ème disque chiffré à un LVM over LUKS

Support Debian
#1

Bonjour,

ce fil eszt en lien avec Problème de superblock du à un probleme de taille de filesystem - #10 par Zargos

J’essaye de retrouver la bonne procédure pour ajouter un nouveau volume physique à un LVM over luks.
J’ai la situation suivante:

  • Disque dev/nvme0n1 partitionné:
# fdisk -l /dev/nvme0n1
Disque /dev/nvme0n1 : 60 GiB, 64424509440 octets, 125829120 secteurs
Modèle de disque : ORCL-VBOX-NVME-VER12                    
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 5B1E83D8-C230-4696-B101-0E828D937E7A

Périphérique    Début       Fin  Secteurs Taille Type
/dev/nvme0n1p1   2048    430079    428032   209M Système EFI
/dev/nvme0n1p2 430080 125827071 125396992  59,8G Système de fichiers Linux

avec un disque /dev/sda disponible. Sur ce disque j’ai partitionné avec LVM.
Toutes les partitions/disques sont les suivants:

# lsblk
NAME                       MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
sda                          8:0    0   60G  0 disk  
sr0                         11:0    1   51M  0 rom   
nvme0n1                    259:0    0   60G  0 disk  
├─nvme0n1p1                259:1    0  209M  0 part  /boot/efi
└─nvme0n1p2                259:2    0 59,8G  0 part  
  └─nvme0n1p2_crypt        254:0    0 59,8G  0 crypt 
    ├─cynv01-swap          254:1    0  2,9G  0 lvm   [SWAP]
    ├─cynv01-boot          254:2    0  244M  0 lvm   /boot
    ├─cynv01-root          254:3    0 15,8G  0 lvm   /
    ├─cynv01-home          254:4    0  6,3G  0 lvm   /home
    ├─cynv01-var           254:5    0 15,8G  0 lvm   /var
    ├─cynv01-var_log       254:6    0  6,3G  0 lvm   /var/log
    ├─cynv01-var_log_audit 254:7    0  6,3G  0 lvm   /var/log/audit
    ├─cynv01-var_tmp       254:8    0  3,1G  0 lvm   /var/tmp
    └─cynv01-tmp           254:9    0  3,1G  0 lvm   /tmp

je veux utiliser le disque /dev/sda pour étendre mes partitions LVM.
Le principe consiste donc a chiffrer mon disque /dev/sda avec les mêmes paramètres que pour /dev/nvme0n1 avec la commande suivante:
cryptsetup luksFormat --pbkdf pbkdf2 --cipher serpent-ecb --hash SHA256 --verify-passphrase /dev/sda
Et j’ai donc:

# lsblk -f
NAME                       FSTYPE      FSVER            LABEL           UUID                                   FSAVAIL FSUSE% MOUNTPOINTS
sda                        crypto_LUKS 2                                a4ee08cf-70e3-4368-afdb-100f885791c6                  
sr0                        iso9660     Joliet Extension VBox_GAs_7.0.14 2024-01-15-14-48-13-93                                
nvme0n1                                                                                                                       
├─nvme0n1p1                vfat        FAT32                            BC56-0CD7                               205,3M     0% /boot/efi
└─nvme0n1p2                crypto_LUKS 2                                25e8d929-99ba-4246-89ac-e35ac2062404                  
  └─nvme0n1p2_crypt        LVM2_member LVM2 001                         tzt0gW-HL68-iX46-sCbo-wrjZ-8a73-k6XoFx                
    ├─cynv01-swap          swap        1                                59afe3b6-c95e-45c4-b768-879254a75ce4                  [SWAP]
    ├─cynv01-boot          ext4        1.0              BOOT            c294aec0-ab7b-4756-8a11-d7e2cd73aaa5      134M    33% /boot
    ├─cynv01-root          ext4        1.0              ROOT            94450822-2534-4f18-a5e6-abab0b37f566      8,9G    37% /
    ├─cynv01-home          ext4        1.0              HOME            976b3cfd-c912-4c2b-9f9f-915a90e393b2      5,6G     4% /home
    ├─cynv01-var           ext4        1.0              VAR             f5c1530c-5d2f-44f1-bcda-764378c3c130     13,9G     4% /var
    ├─cynv01-var_log       ext4        1.0              LOG             d35eb24e-c7dd-463f-b065-4558922b3097      5,8G     1% /var/log
    ├─cynv01-var_log_audit ext4        1.0              AUDIT           95f6fa23-3be9-44cb-ab7a-2748569b0a19      5,8G     0% /var/log/audit
    ├─cynv01-var_tmp       ext4        1.0              VARTMP          208a3710-5a48-4e51-af6b-6d04e1e081d7      2,8G     0% /var/tmp
    └─cynv01-tmp           ext4        1.0              TMP             dff98304-ab98-4255-b67c-8d85b4235f3e      2,8G     0% /tmp

Dans lequel on voit bien /dev/sda chiffré.

Ensuite je peux ouvrir ce disque chiffré:
cryptsetup luksOpen /dev/sda sda_crypt
et j’ai bien:

# lsblk -f
NAME                       FSTYPE      FSVER            LABEL           UUID                                   FSAVAIL FSUSE% MOUNTPOINTS
sda                        crypto_LUKS 2                                a4ee08cf-70e3-4368-afdb-100f885791c6                  
└─sda_crypt                                                                                                                   
sr0                        iso9660     Joliet Extension VBox_GAs_7.0.14 2024-01-15-14-48-13-93                                
nvme0n1                                                                                                                       
├─nvme0n1p1                vfat        FAT32                            BC56-0CD7                               205,3M     0% /boot/efi
└─nvme0n1p2                crypto_LUKS 2                                25e8d929-99ba-4246-89ac-e35ac2062404                  
  └─nvme0n1p2_crypt        LVM2_member LVM2 001                         tzt0gW-HL68-iX46-sCbo-wrjZ-8a73-k6XoFx

Je récupère l’UUID du disque /dev/sda pour l’ajouter à /etc/crypttab:
lsblk -f
et dans /etc/crypttab:

# cat /etc/crypttab 
nvme0n1p2_crypt UUID=25e8d929-99ba-4246-89ac-e35ac2062404 none luks,discard
sda_crypt	UUID=a4ee08cf-70e3-4368-afdb-100f885791c6 none luks,discard

Pour la prise en compte du déchiffrement au démarrage:
update-initramfs -c -k all

Quand je redémarre, le système démarre correctement et j’ai bien les deux disques ouvert déchiffrés:

$ lsblk
NAME                       MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
sda                          8:0    0   60G  0 disk  
└─sda_crypt                254:10   0   60G  0 crypt 
sr0                         11:0    1   51M  0 rom   
nvme0n1                    259:0    0   60G  0 disk  
├─nvme0n1p1                259:1    0  209M  0 part  /boot/efi
└─nvme0n1p2                259:2    0 59,8G  0 part  
  └─nvme0n1p2_crypt        254:0    0 59,8G  0 crypt 
    ├─cynv01-swap          254:1    0  2,9G  0 lvm   [SWAP]
    ├─cynv01-boot          254:2    0  244M  0 lvm   /boot
    ├─cynv01-root          254:3    0 15,8G  0 lvm   /
    ├─cynv01-home          254:4    0  6,3G  0 lvm   /home
    ├─cynv01-var           254:5    0 15,8G  0 lvm   /var
    ├─cynv01-var_log       254:6    0  6,3G  0 lvm   /var/log
    ├─cynv01-var_log_audit 254:7    0  6,3G  0 lvm   /var/log/audit
    ├─cynv01-var_tmp       254:8    0  3,1G  0 lvm   /var/tmp
    └─cynv01-tmp           254:9    0  3,1G  0 lvm   /tmp

Ensuite, j’ajoute /dev/mapper/sda_crypt à mes PV:

# pvcreate /dev/mapper/sda_crypt 
  Physical volume "/dev/mapper/sda_crypt" successfully created.
root@dsrvtest01:~# pvs
  PV                          VG     Fmt  Attr PSize   PFree 
  /dev/mapper/nvme0n1p2_crypt cynv01 lvm2 a--  <59,78g 20,00m
  /dev/mapper/sda_crypt              lvm2 ---   59,98g 59,98g

Puis j’ajoute le PV à mon VG existant:

# vgextend cynv01 /dev/mapper/sda_crypt 
  Volume group "cynv01" successfully extended
root@dsrvtest01:~# vgs
  VG     #PV #LV #SN Attr   VSize    VFree 
  cynv01   2   9   0 wz--n- <119,76g 60,00g

Je redémarre et j’obtiens un joli plantage:
je ne comprends pas ce qui ne marche pas. J’ai essaye avec une deuxième update-initramfs mais ça ne change rien.

image

Ça ne marche pas non plus si je créé une partition sur sda (/dev/sda1) que formate en chiffré.

#2

Il n’y a rien à faire, impossible de trouver une solution où que ce soit pour l’ajout d’un disque chiffré dans un PV existant qui soit fonctionnel.

Créer le disque chiffré, pas de soucis. L’ouvrir puis l’ajouter au PV puis au VG pas de soucis non plus.
Mais si on reboot ça ne marche plus y compris après un update-initramfs -c -k all

#3

Salut,

Ajouter un disque chiffré à un volume physique (PV) existant dans Linux peut être compliqué. Je ne sais pas si cela t’aidera, mais voici les étapes que je pense logiques :

Préparer le nouveau disque chiffré
Créer un nouveau volume physique (pvcreate)
Ajouter ce PV au groupe de volumes existant (vgextend)
Étendre les volumes logiques (lvextend)
Étendre les systèmes de fichiers (resize2fs)
Mise à jour de l'initramfs

Je suis curieux de voir comment cette discussion évoluera sur ce sujet. Si je ne vois pas de progrès, je vais tester ça sur une VM pour mieux comprendre et trouver une solution et au mieux tester la procédure qui solutionne ton point de blocage.

#4

C’est exactement ce que j’ai fait mais ça ne marche pas je me retrouve au démarrage avec le shell initramfs.

J’ai essayé de faire une installation avec la dernière ISO netinst avec les deux disques chiffrés et ça ne marche pas non plus.

Alors que j’arrive bien, lors d’un ajout de disque, à démarrer avec le déchiffrement des deux disques (avant d’ajouter le PV et de modifier le VG), l’installation elle est incapable de déchiffrer les deux disques, elle s’arrête au disque qui porte la partition EFI et la partition /boot (non chiffrées).

En mode Rescue, j’ai pu vérifier le /etc/crypttab qui est correct, j’ai refait un update-initramfs -c -k all comme d’habitude, suivi d’un update-grub, mais rien n’y fait. En plus j’ai malheureusement pour moi oublié d’autoriser dans l’EFI l’utilisation du disque DVD pour l’iso pour refaire un mode Rescue… Mais en modifiant ma VM (retirer l’EFI) j’ai pu demarrer :slight_smile:

#5

J’ai une question:
Si je refait un update-initramfs est-il nécessaire de refaire un grub-install ou un update-grub?

#6

Dans tous les cas, un ‹ update-grub › ne comporte pas de risque, donc pourquoi ne pas tester ?
Pour moi les processus de mise à jour de l’initramfs et de mise à jour de GRUB ne sont pas directement liés. Il me semble que l’un n’est pas nécessairement déclenché par l’autre, ou du moins il ne peuvent pas l’être.

#7

En fait, dès que je met le second disque dans le PV et le PV ainsi créé dans le VG j’ai un echec de boot car l’initram n’a plus le second disque dans sont crypttab.

sous initramfs il y a un fichier cryptsetup/cryptab qui est sensé avoir les disques mis dans /etc/crypttab.

Seulement voilà, dès lors que je l’ai ajouté dans LVM il n’y est plus.

Lors d’un update-initramfs -c -k all il ne considère que le disque de démarrage qui contient /boot et/ou /boot/efi. Il ne prend pas l’autre disque qui est pourtant dans /etc/crypttab.

De facto, le système ne peut donc pas démarrer car il manque un disque dans le LVM car celui-ci n’est pas déchiffré.

#8

Yalllahhhhh!!! j’ai enfin trouvé :slight_smile: ce n’est aps encore parfait (le système me demande le mot de passe de chaque disque).

Pour déchiffrer les disque il faut une syntaxe dans /etc/crypttab qui indique que initramfs doit déchiffrer le disque en question, ce qui donne dans mon cas les deux lignes suivante. A la deuxième ligne, l’option iniramfs indique à l’init de déchiffrer le disque sous initramfs:

sda2_crypt UUID=xxxxxxxx none luks
sdb1_crypt UUID=xxxxxxxx none luks,initramfs

Il ne me reste plus qu’à trouver comment faire en sorte de n’entrer le mot de passe qu’une seule fois.
Mais aucune des solutions trouvées sur internet ne fonctionne… Je dois taper le mots de passe à chaque disque.

1 J'aime
#9

Assure-toi que les UUID des disques sont correctement définis :
sudo blkid
Ensuite, configure le déblocage multiple de LUKS dans le fichier :
/etc/cryptsetup-initramfs/conf-hook
Vérifie si la variable MULTIPATH est correctement positionnée sur « yes ». Si la variable n’existe pas, créez-la :
MULTIPATH=yes

Mise à jour :
sudo update-initramfs -u
ou
update-initramfs -c -k all
Suivant tes besoins

Pour finir il faudra à mon avis, configurer le déblocage automatique, puis remettre à jour initramfs.

#10

C’était déjà le cas

J’ai ajouté, mais ça ne change rien

Qu’entends-tu par là?

En tout cas une chose est claire, l’installer est à la ramasse pour ce type d’installation.

#11

Une fois que la ou les clés sont générées, tu dois les ajouter au disque chiffré. Ensuite, tu devras indiquer au système d’utiliser cette clé pour déverrouiller automatiquement le disque au démarrage dans /etc/crypttab avec l’option:
keyfile=/ton/chemin/de/clé.
Ensuite, tu dois remettre à jour avec sudo update-initramfs.

Je n’ai pas essayé en pratique, je pourrais le faire demain si j’ai un moment en créant une VM et un disque virtuel, puis exécuter différents tests.

La seule chose étant que cette commande qui dit au système d’utiliser cette clé devrait ressembler à quelque chose comme ça :
sda2_crypt UUID=xxxxxxxx none luks,keyfile=/chemin/de/ta/clé

Dans ma logique, après avoir vérifié que toutes les configurations déclarées en amont ont été prises en compte par le système, je m’assure que tout est correctement configuré. Ensuite, je peux demander au système de prendre en compte les configurations précédentes pour automatiser le processus désiré, je reste convaincu que cette démarche soit juste.
Activation de multipath
Déclaration de keyfile
Commande pour automatiser le processus
Mise à jour de l’initramfs
En espérant que cela puisse t’aider :slight_smile:

#12

Je t’arrête de suite, pas de clefs sur la machine :slight_smile:
C’est pour le moment saisie au clavier. Ensuite dès que j’aurais avancé, ce sera avec une clef Yubikey 5.

en fait c’est :
sda2_crypt UUID=xxxxxxxx keyfile=/chemin/de/ta/clé luks

de quelle automatisation parles-tu?

#13

Si tu demandes au système de se connecter correctement au disque à chaque démarrage, nous parlons bien ici d’automatisation.
Après, si tu m’arrêtes tout de suite en ce qui concerne la clé, je reste bloqué avec des inconnus.
Je vais suivre cette discussion afin de découvrir la finalité qui permettra la résolution du ou des éléments bloquants auxquels tu as été confronté.
Personnellement, j’attends de me retrouver dans la même situation que la tienne pour découvrir et trouver une solution. Désolé de t’avoir fait perdre ton temps.

#14

Ce n’est pas le cas :slight_smile:
l’informatique par essence ou plutot origine c’est de l’automatisation, même si l’automatisme est une autre discipline (j’ai pratiqué les deux) :slight_smile:

Quand je disais pas de clef sur la machine, carf si un fichier de clef accessible à un moment ou un autre se trouve sur la machine alors il ne sert à rien d’en avoir.
je ne parle pas bien sur de clef issues de clefs USB spécialisées ou de TPM.

je publierais mes avancées au fur et à mesure. Pour ce qui est du crypttab/initramfs, je ferais un truc et astuce pour en laisser une trace facilement utilisable.

#15

Bon après pas mal de tests la conclusion est un peu déprimante: l’installateur Debian n’est pas capable de faire une installation LVM chiffrée de plus d’un disque correctement.
OLn savait déjà qu’on ne pouvait pas chiffrer /boiot car celui-ci chiffre par défaut en argon2i alors que grub n’est compatible qu’avec du pbkdf2.

Coté initramfs impossible de trovuer une configuration de /etc/crypttab qui déchiffre directement les deux disques avec le mot de passe entré une seule fois au clavier.
Ce qui, quand on chiffre le boot fait trois mot de passe à entrer.

Coté installateur, Debian a encore pas mal de progrès à faire.

Pour ce qui est de simple-cdd et preseed, impossible de faire une configuration LVM avec un seul VG mais deux disque, que ce soit chiffré ou non. Ça ne marche pas. Comme c’est lié à l’installateur cela me parait logique.