[cryptsetup] Device /dev/sdc3 is not a valid LUKS device

Support Debian
#1

Bonjour à tous,

J’ai eu une rupture de courant alors que mon ancien SSD partiellement chiffré était monté sur ma Debian Buster.
Depuis, à chaque tentative de montage des partitions chiffrées de ce SSD j’obtiens une erreur “Device /dev/sdc3 is not a valid LUKS device” :

# fdisk -l
[...]
Disk /dev/sdc: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Disk model: 2105            
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x9e1584aa


Device     Boot     Start       End   Sectors  Size Id Type
/dev/sdc1  *         2048   1953791   1951744  953M 83 Linux
/dev/sdc2         1953792  70313983  68360192 32.6G 83 Linux
/dev/sdc3        70313984 472852479 402538496  192G 83 Linux
/dev/sdc4       472852480 488396799  15544320  7.4G 83 Linux

# cryptsetup luksOpen /dev/sdc3 old-home
Device /dev/sdc3 is not a valid LUKS device.

# cryptsetup luksOpen /dev/sdc4 swap
Device /dev/sdc4 is not a valid LUKS device.

# cryptsetup -v isLuks /dev/sdc3
Command failed with code -1 (wrong or missing parameters).

# cryptsetup -v isLuks /dev/sdc4
Command failed with code -1 (wrong or missing parameters).

Pour info, les partitions sdc1 et sdc2 non chiffrées du même SSD se monte correctement. (sdc4 = swap chiffrée avec clé aléatoire)
Et ça ne vient pas - à priori - de LUKS puisque mes autres partitions chiffrées sont correctement déchiffrées :

# ll /dev/mapper/
total 0
drwxr-xr-x  2 root root     100 Oct 14 11:51 ./
drwxr-xr-x 19 root root    3700 Oct 14 17:45 ../
crw-------  1 root root 10, 236 Oct 14 11:50 control
lrwxrwxrwx  1 root root       7 Oct 14 11:50 sda3_crypt -> ../dm-0
lrwxrwxrwx  1 root root       7 Oct 14 11:51 sdb1_crypt -> ../dm-1

Après recherches, j’ai bien trouvé sur le Net des personnes ayant eu ce même message d’erreur mais, soit ils n’ont pas eu de réponses, soit le problème était différent et donc la solution inadaptée.

Quelqu’un pourrait me conseiller/m’aider svp ?

Merci d’avance,
R-One

#2

A ma connaissance, on ne peut pas utiliser une clé aléatoire avec LUKS, seulement avec “plain dm-crypt”.
Que disent blkid et file -s de ces deux partitions ?
Que contient /etc/crypttab ?

#3

Merci pour ta réponse PascalHambourg.

Voici le résultat des commandes :
# blkid /dev/sdc3
/dev/sdc3: PARTUUID=“9e1584aa-03”
# file -s /dev/sdc3
/dev/sdc3: data
# blkid /dev/sdc4
/dev/sdc4: PARTUUID=“9e1584aa-04”
# file -s /dev/sdc4
/dev/sdc4: data
# cat /etc/crypttab
sda3_crypt /dev/sda3 /dev/urandom cipher=aes-xts-plain64,size=256,swap
sdb1_crypt UUID=5c8c6ef1-d9ed-40fe-9606-698d8f0edc72 none luks

#4

Je ne sais plus si file sait identifier un en-tête LUKS, mais blkid le sait, et il n’en trouve pas dans ces deux partitions. Elles ne sont pas non plus déclarées dans /etc/crypttab. Comment étaient-elles ouvertes auparavant ? Est-ce qu’elles appartiennent à ce système ou à une autre installation ?

Notes :

  • Comme je l’expliquais, le swap chiffré avec clé aléatoire sda3_crypt défini dans /etc/crypttab n’utilise pas LUKS mais “plain dm-crypt”, contrairement à l’autre volume sdb1_crypt.

  • Spécifier le volume physique par son nom de périphérique /dev/sd* dans /etc/crypttab est une erreur à éviter, comme dans /etc/fstab. Les noms /dev/sd* ne sont pas stables et peuvent changer à chaque démarrage lorsqu’il y a plusieurs “disques”. Dans le cas d’un volume chiffré avec LUKS, la conséquence sera seulement l’impossibilité de l’ouvrir (c’est pourquoi on identifie le volume avec l’UUID de son en-tête LUKS comme ici pour sdb1_crypt). Mais cette erreur peut avoir des conséquences beaucoup plus graves avec le chiffrement plain dm-crypt, car il n’y a aucune vérification du format de la partition ; si ce n’est pas la bonne partition, elle sera utilisée quand même et son contenu sera écrasé à la première écriture (donc à l’ouverture puisque l’option “swap” provoque le formatage en tant que swap). On ne peut pas utiliser l’UUID car il n’y en a pas, mais on peut utiliser un des alias persistants créés dans /dev/disk/by-{id,partuuid,partlabel}/ qui pointent vers la partition.

#5

Alors :

  • sda (SSD 500Go) et sdb (HD 1To) appartiennent tous les deux à l’install d’une Debian Stretch, mise à jour dernièrement (mais après la coupure de courant) en Debian Buster et que j’utilise actuellement.
  • sdc (SSH 256Go) quant à lui appartient à une install Debian Stretch faite sur un ancien pc.

# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 465.8G 0 disk
├─sda1 8:1 0 953M 0 part /boot
├─sda2 8:2 0 457.4G 0 part /
└─sda3 8:3 0 7.5G 0 part
└─sda3_crypt 254:0 0 7.5G 0 crypt [SWAP]
sdb 8:16 0 931.5G 0 disk
└─sdb1 8:17 0 931.5G 0 part
└─sdb1_crypt 254:1 0 931.5G 0 crypt /home
sdc 8:32 0 232.9G 0 disk
├─sdc1 8:33 0 953M 0 part /media/erwan/a58f0c01-3f11-4725-b9f1-510528517781
├─sdc2 8:34 0 32.6G 0 part /media/erwan/fe8f7c6c-e7e7-4722-8f44-8756738f80be
├─sdc3 8:35 0 192G 0 part
└─sdc4 8:36 0 7.4G 0 part
sr0 11:0 1 1024M 0 rom

Jusqu’à présent, après démarrage de mon pc, je branchais et montais régulièrement la partition /home chiffrée (sdc3) du SSD de 256Go, via une station d’accueil USB et en tapant les commandes suivantes :

# cryptsetup luksOpen /dev/sdc3 old-home

et une fois la passphrase correctement renseignée :

# mount /dev/mapper/old-home /mnt/usb

Les partitions sdc1 et sdc2 se montent automatiquement via l’explorateur de fichiers que j’utilise : “SpaceFM”.

Sinon, merci pour tes conseils sur la façon de renseigner /etc/crypttab et/ou /etc/fstab : c’est très instructif ! J’ai donc modifié /etc/crypttab de la sorte :

# cat /etc/crypttab
sda3_crypt /dev/disk/by-partuuid/cf196c2f-03 /dev/urandom cipher=aes-xts-plain64,size=256,swap
sdb1_crypt UUID=5c8c6ef1-d9ed-40fe-9606-698d8f0edc72 none luks

(Pour info, le contenu de /etc/crypttab indiqué dans mon précédent post était celui crée par l’install initiale de Debian Stretch)

Tu penses qu’il y aurait pu avoir “mélange” entre les partitions et que l’actuelle sdc3 ait été formatée en tant que swap ? (Bien que - sauf erreur de ma part - le SSD de 256Go n’est normalement pas branché au démarrage du pc)

#6

Je ne peux pas m’empêcher de remarquer que l’ancienne partition home /dev/sdc3 a le même numéro que la partition de swap chiffré actuelle /dev/sda3. S’il est arrivé une fois que le SSD de 250 Go soit présent au démarrage et vu comme /dev/sda au lieu de /dev/sdc, alors l’ancienne partition home s’est retrouvée vue comme /dev/sda3 et a été réinitialisée comme swap chiffré conformément au contenu dangereux de /etc/crypttab. Je sais que c’est l’installateur Debian qui crée /etc/crypttab de cette façon, et je le déplore. Si tu n’avais pas sauvegardé l’en-tête LUKS de la partition, elle est irrécupérable. Même dans le cas contraire, son système de fichiers sera probablement endommagé.

#7

Ton hypothèse m’a travaillé presque toute la nuit !
Au vu de tes explications, c’est effectivement ce que je crains.

Je me pose cependant une question : au démarrage, l’ordinateur a 2 possibilités de boot, vu que chacun des 2 SSD contient une partition /boot.

  • Si le SSD de 500Go est vu comme /dev/sda (la normalité) alors il n’y a pas pu avoir “écrasement” de /dev/sdc3 : en effet, c’est le fichier /etc/crypttab de /dev/sda (et donc du SSD de 500Go) qui a été pris en compte. Dans ce cas la ligne contenant la mention /dev/sda3 de ce fichier pointe bien vers la bonne partition. (la 3ème de ce même SSD de 500Go, c’est à dire la swap)

  • Si par contre, c’est le SSD de 256Go qui est vu comme /dev/sda (et le SSD de 500Go comme /dev/sdc) c’est toujours le fichier /etc/crypttab de /dev/sda (et donc ici du SSD de 256Go) qui a été pris en compte.

Or celui-ci contient :

$ cat /media/erwan/fe8f7c6c-e7e7-4722-8f44-8756738f80be/etc/crypttab
sda3_crypt UUID=1e012b00-8a68-461d-8202-c92e65de1e4f none luks
sda4_crypt /dev/sda4 /dev/urandom cipher=aes-xts-plain64,size=256,swap

Comment y aurait-il pu avoir “écrasement” en ce cas ?

Je ne sais pas si je m’explique correctement :roll_eyes:
En fait je comprends ta logique, mais j’avoue ne pas savoir comment l’appliquer dans ce qui semble m’être arrivé.

#8

PascalHambourg, ton hypothèse semble malheureusement se confirmer de plus en plus :

# cryptsetup luksDump /dev/sdc3
Device /dev/sdc3 is not a valid LUKS device.
# cryptsetup luksDump /dev/sdc4
Device /dev/sdc4 is not a valid LUKS device.
# cryptsetup luksDump /dev/sda3
Device /dev/sda3 is not a valid LUKS device.
# cryptsetup luksDump /dev/sdb1
LUKS header information for /dev/sdb1

Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha256
Payload offset: 4096
MK bits: 512
MK digest: 9a 62 35 7a 74 bb 25 ff 38 ce c4 90 1c 28 ae 0c 50 5f 2e 37
MK salt: 69 5f f0 5c cf b9 98 d1 14 99 b7 ae f1 a8 b0 7a
42 a2 f6 60 20 ac 0c bd da 8f 80 d8 5e 31 9e 66
MK iterations: 197500
UUID: 5c8c6ef1-d9ed-40fe-9606-698d8f0edc72

Key Slot 0: ENABLED
Iterations: 1610062
Salt: 3d 0c af 5f 93 04 ba 9b b2 82 55 10 fd d5 cb 03
44 5c c3 22 7f b2 9f fc d7 0e a0 73 95 36 7f 3f
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

:sob:

Il n’y a pas un moyen d’être sûr à 100%, genre consulter les valeurs hexadécimales du header de la partition ?
J’imagine qu’une partition “plain dm-crypt” doit avoir un header particulier par rapport à un header LUKS, non ?

Sinon pour info, je n’ai aucune sauvegarde de l’en-tête LUKS (je ne savais même pas qu’il fallait le faire !) ni aucune sauvegarde de la partition : je m’apprêtais justement à en faire une lorsque la coupure a eu lieu ! (elle a même flingué un des 4 disques constituant mon raid-Z2, mais je n’ai perdu ici aucune donnée)

#9

Il n’y a pas de corrélation entre le disque de boot ni la numérotation des disques par le BIOS/UEFI et le nommage des disques /dev/sd*. Les disques sont nommés dans l’ordre de leur détection par le noyau, ordre qui n’est pas déterministe. Le disque de boot peut très bien être vu comme /dev/sdb ou /dev/sdc.

Le pilote usb-storage qui gère les disques USB introduit un délai (1 seconde par défaut) qui retarde la détection et le nommage des disques USB, de sorte que les disques internes sont généralement détectés et nommés avant. Mais les pilotes sont chargés et détectent les périphériques de façon asynchrone, et il n’est pas impossible que le pilote USB soit chargé avant le pilote SATA et que l’intervalle entre la detection du disque USB et des disques SATA soit supérieur à 1 seconde, conduisant le disque USB à être nommé “sda”.

Tu pourrais rechercher dans les anciens logs du noyau /var/log/kern.* s’il est arrivé que le disque USB soit vu comme “sda”.

Tu peux examiner le contenu hexadecimal d’une partition avec la commande hd (hexdump), en limitant la taille aux xxx premiers octets avec l’option -n xxx.

Mais non, le chiffrement “plain dm-crypt” n’a pas d’en-tête particulier. C’est du contenu chiffré par dm-crypt brut. C’est pourquoi il faut spécifier les paramètres de chiffrement lors de l’ouverture avec cryptsetup ou crypttab (ex : cipher=aes-xts-plain64,size=256). Il n’y a aucune vérification de validité de la clé de chiffrement spécifiée : les données sont simplement chiffrées et déchiffrées avec cette clé, que le contenu soit intelligible ou non.

Le format LUKS, c’est un en-tête LUKS qui contient notamment les paramètres de chiffrement, la clé de chiffrement (protégée par 1 à 8 passphrases) et un UUID pour l’identifier, suivi par les données chiffrées par dm-crypt.