Accès partition LVM LUKS mode rescue

Support Debian
#12

En effet au multiples essais je suis passé du mainRoot à md126_crypt et pas mis la bonne « capture »
Mon oeil non aguerri n’y voyant aucune gêne
désolé :pensive:
merci de ta patience

Dans l’intervalle et la précipitation j’ai relancé l’installation avec /boot chiffré et coller 1Go d’espace, heureusement que ton conseil ne tendait pas au 2Go…
J’étais tombé sur la page que tu mets en référence qui m’a effrayée
j’ai aussi lu rapidement https://www.blakehartshorn.com/installing-debian-on-existing-encrypted-lvm/

Qui si j’ai bien compris permet de chiffrer /boot post install
Je n’ai pas le choix car j’ai tenté la réinstall full chiffrée et me retrouve devant la console grub et ne sait pas encore comment on boot dans ce cas de figure.

Pour le reste des commandes que tu me suggères quand j’aurais abouti à une installation fonctionnelle, je regarderai car j’ai besoin de pouvoir être sûr de pouvoir accéder à mes partitions depuis une rescue avant d’y coller touts les données de ma vie

Encore merci

edit: https://www.blakehartshorn.com/installing-debian-on-existing-encrypted-lvm/ implique pouvoir accéder à un seconde console ce que IPMI ne permet apparement pas.

#13

Lors de l’installation ? L’installateur dispose de 2 consoles virtuelles tty2 et tty3 accessibles avec Ctrl+Alt+F2 et F3.

#14

Oui mais sur un serveur dédié avec kvm IPMI
je n’arrive à ouvrir aucun console soit directement en pressant les touches du clavier soit en utilisant les « boutons » de l’interface IPMI qui propose de maintenir Ctrl et ALT enfoncée

petite capture pour être plus clair
image

edit: je viens d réessayer c’est passé
Merci je continue

#15

Bonjour

En voyant ta capture d’écran, je constate que tu utilises le mode texte pour l’installation.

Quand on est déjà en mode texte, la touche Ctrl n’est pas nécessaire, c’est juste quand le programme d’installation s’affiche en mode graphique que la touche Ctrl est nécessaire.

Pour passer d’une console à l’autre quand on est en mode texte, il suffit de maintenir la touche Alt appuyée tout en pressant sur une touche de F2 à F4,

Alt+F1 permet d’accéder à la console texte utilisée pour l’affichage des fenêtres de dialogue du programme d’installation, et la console 4, qui est accessible par Alt+F4 depuis le mode texte, affiche d’autres informations intéressantes.

#16

Oui je ne l’avais jamais fait comme ça auparavant, toujours eu un accès physique à la machine avec écran clavier branché directement dessus
Soit j’ai mal pressé le clavier soit je ne sais pas mais devant l’étonnement de # PascalHambourg j’ai ressayé et c’est passé avec le bouton ALT de l’interface + F2

Bon cela dit vu mon expérience avec LVM et LUKS, je me retrouve au même point qu’au début de mon post.
je dois déverouiller ma partition qui est /boot « LUKSée » et avec un LV il s’agit de /dev/nvme0n1p2
Dans la seconde console ouverte si je saisis

cryptsetup luksOpen /dev/md4 boot-crypt

il répond

Device /dev/md4 does not exist or access denied

alors qu’il censé être celui de /boot

cat /proc/mdstat

répond

cat: can't open '/proc/mdstat': No such fil or directory

et

cryptsetup luksOpen /dev/nvme0n1p3 crypt-boot

répond

Device /dev/nvme0n1p3 is not a valid LUKS device

j’ai bien fait attention à bien retranscrire fidèlement saisies et retours

image

blkid donne
image

lsblk n’est pas dispo et pas installable on dirait

Les partition préparées avec Gparted avant installation
image

nvme0n1p2 est une grappe RAID1 soft, nvme0n1p3 en est une autre

#17

Ca ne peut peut pas marcher car dans la commande c’est le montage raid qui est prix en compte. Normalement sur ce RAID (qui n’est pas une partition) il y a une partition qui est mise en place. C’est cette partition qui est chiffrée, et c’est donc celle ci dont il faut faire l’ouverture luksOpen.

En fait le tout est constituée comme ci-après (le niveau le plus bas sur la dernière ligne):
[ Partitions LVM ]
[ Partition Luks ]
[ RAID md0 | RAID md1 ]

Et qui plus est, avec le fait que le /boot ne peux pas être chiffré, il faut deux raids.
[ Partitions LVM ]
[ Partition Luks ]
[ RAID md2 | RAID md3 ]

[ Partition boot ]
[ RAID md0 | RAID md1 ]

#18

Non. Ou alors il faut vraiment le faire exprès. En tout cas l’installateur ne le fait pas.

#19

Le pilote RAID n’est pas chargé et les ensembles RAID ne sont pas actifs. Dans quel environnement es-tu ? L’installateur ? Dans quel mode ? A quel stade ?

#20

Je suis bien dans l’installeur
j’essaie de suivre ce qui est indiqué dans cet article pour obtenir mon /boot chiffré
https://www.blakehartshorn.com/installing-debian-on-existing-encrypted-lvm/

avant la détection de disque je passe sur une autre console et les commandes passées et les résultats de mon dernier post sont dans cette console (avec l’installeur lancé en mode expert lol )

il y a bien deux RAID1 soft je prépare les partitions avec Gparted comme dans la capture que j’ai mise pour avoir la partition de boot EFI
je chiffre chaque grappe et ensuite configure LVM, création des vg de chaque RAID et LV ensuite
peut-être est-ce incorecte mais avant de vouloir monter une autre grappe RAID1 constituée de deux HDD de 4to sans avoir renseigné crypttab mais fstab oui et laisser /boot sur un RAID1 non chiffré cela bootait et j’avais accès au système
Avec /boot chiffré c’est la console grub qui se lance au boot et comme je disais je ne sais pas booter depuis

là ou je suis perdu c’est que même si je lui indique une partition à monter après ouverture avec cryptsetup luksOpen cela ne donne rien
après j’ai fait des essais qui doivent vous paraitre dingue pour essayer et peut être comprendre ce qui m’échappe sans RAID1 je n’ai jamais connu ce genre de soucis depuis longtemps (travail sur station de travail)

apt et apt-get ne sont pas dispo sur la console de l’installeur ce que je ne savais pas
il me répond

/bin:sh: apt-get (ou apt) : not found

vgscan, vgchange -ay, lvs ou lvdisplay me rendent la main sans réponse

Merci à vous

#21

Je pense que c’est trop tôt pour que le RAID soit activé. Il faut au moins attendre la détection des disques, sinon le partitionneur.

Pourquoi as-tu besoin d’apt-get ?

Mon avis : ne cherche pas à chiffrer /boot lors de l’installation. Tu vas t’embêter pour rien, il vaut mieux le faire après.

#22

apt et apt-get c’était pour avoir les commandes mdadm et lsblk par exemple mais je dois être à coté de la plaque

du coup en effet je me disais que j’allais recommencer et chiffrer /boot après mais je me dis que ce qui complique c’est la présence du RAID1 car dans l’article que je suis pour chiffrer /boot après install, l’auteur n’utilise pas de RAID1 soft en tous cas

Quoiqu’il en soit merci pour votre intérêt et je ne pense pas en rajouter aujourd’hui :crossed_fingers: le temps de digérer https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html pour le mettre en application je pense que cela me prendra plus que l’apm :sweat_smile:

Mon partitionnement sachant que sda et sdb sont des disques SATA qui ne contiendront pas le système
le départ du problème…

partitions1
partitions2

dans main (/dev/md126) je crée 3 LV pour / , /home et une swap

#23

lsblk n’est pas disponible dans l’installateur. Pour mdadm, si tu ne peux pas attendre les étapes suivantes pour qu’il soit disponible tu peux exécuter

anna-install mdadm-udeb

Tu auras peut-être besoin d’installer le paquet md-modules-5.10.0-16-amd64-di (ajuster à la version du noyau de l’installateur) s’il ne l’est pas déjà. Et peut-être exécuter depmod ensuite pour que les modules soient utilisables avec modprobe.

Et cela complique d’autant plus lors de l’installation. Après l’installation, je ne vois pas trop pourquoi ça compliquerait, il devrait suffire d’adapter la procédure aux noms de périphériques utilisés. Mais je ne l’ai pas lue.

Et la touche finale, ce sera la mise en place de la redondance pour l’amorçage EFI. Je te souhaite bien du plaisir.

#24

mauvaise idée, ce type d’installation c’est bien quand tu es un expert sinon tu t’engages dans un chemin dont tu ne verras pas la fin.

En fait, tu t’embêtes pour rien.
perso je fais une installation normale chifrée avec tous qui va bien sur un disque.
ensuite sur l’autre disque je créée le premier node du raid en lui specifiant que l’autre noeud est inactif.
Puis je déplace ce qui est sur le premier disque sur le deuxième disque (noeud 1 du raid)
Ensuite je definie le second noeud du raid, et je laisse faire le Raid pour synchroniser les deux noeud.
ne reste plus qu’a s’assurer que le bootloader pointe corectement

Certes c’est une méthode qui est à l’origine utilisée pour passer d’une machine sans raid à une machine en raid 1

Pour le EFI ca marche sns soucis, mais il te faut une grappe raid pour l’efi et une autre pour le reste

#25

Là, nous sommes d’accord.

Là par contre, je trouve que ça complique inutilement. Je ne vois aucune raison de ne pas faire l’installation initiale directement en RAID.

Là non plus je ne suis pas d’accord. Une partition EFI en RAID c’est loin d’être sans souci pour une raison simple : l’EFI ne reconnaît pas le format RAID logiciel de Linux.

#26

Oui aussi je viens de le faire vite fait sur une VM Virtualbox entre mon message precedent et celui-ci (VM non EFI par contre).

j’ai une machine EFI avec un disque 1To NVME et 1 To SSD qui est en raid et qui tourne très bien depuis au moins un an.

root@dsrvbull01:~# lsblk
NAME                         MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                            8:0    0 931,5G  0 disk
├─sda1                         8:1    0   285M  0 part
│ └─md0                        9:0    0 284,9M  0 raid1 /boot/efi
└─sda2                         8:2    0 931,2G  0 part
  └─md1                        9:1    0 931,1G  0 raid1
    ├─BULL01VG01-swap        253:0    0   7,4G  0 lvm   [SWAP]
    ├─BULL01VG01-root        253:1    0  23,3G  0 lvm   /
    ├─BULL01VG01-home        253:2    0   4,7G  0 lvm   /home
    ├─BULL01VG01-var         253:3    0  43,3G  0 lvm   /var
    ├─BULL01VG01-tmp         253:4    0   1,9G  0 lvm   /tmp
    ├─BULL01VG01-varlog      253:5    0  14,3G  0 lvm   /var/log
    ├─BULL01VG01-varlogaudit 253:6    0   4,7G  0 lvm   /var/log/audit
    └─BULL01VG01-vartmp      253:7    0   1,9G  0 lvm   /var/tmp
nvme0n1                      259:0    0 931,5G  0 disk
├─nvme0n1p1                  259:1    0   285M  0 part
│ └─md0                        9:0    0 284,9M  0 raid1 /boot/efi
└─nvme0n1p2                  259:2    0 931,2G  0 part
  └─md1                        9:1    0 931,1G  0 raid1
    ├─BULL01VG01-swap        253:0    0   7,4G  0 lvm   [SWAP]
    ├─BULL01VG01-root        253:1    0  23,3G  0 lvm   /
    ├─BULL01VG01-home        253:2    0   4,7G  0 lvm   /home
    ├─BULL01VG01-var         253:3    0  43,3G  0 lvm   /var
    ├─BULL01VG01-tmp         253:4    0   1,9G  0 lvm   /tmp
    ├─BULL01VG01-varlog      253:5    0  14,3G  0 lvm   /var/log
    ├─BULL01VG01-varlogaudit 253:6    0   4,7G  0 lvm   /var/log/audit
    └─BULL01VG01-vartmp      253:7    0   1,9G  0 lvm   /var/tmp
#27

:sweat_smile: Ben je ne sais pas comment au faire au plus simple, enfin je ne savais pas merci pour les partages d’infos

Je veux absolument pouvoir chiffrer /boot car un admin d’un ancien boulot le seul où 80% du parc était sous GNU/Linux (postes de travail et serveurs) et je l’ai lu dans un post sur debian-fr , disaient que c’est le seul moyen de rendre la machine totalement secure face à un accès physique. Je ne parle pas d’un « piratage » par le réseau machine allumée comme on n’a pas pu me « vanter le manque d’intérêt » de chiffrer un serveur.

double :sweat_smile: moi qui me disait je devrais tester sur une VM… mais je ne suis pas sûr de pouvoir le faire en 30min

donc sur ta machine /boot est chiffrée dans le RAID principal et avec une autre grappe RAID pour /boot/efi ? non chiffrée?

le fait de vouloir chiffrer /boot? ou la méthode pour y arriver?

#28

Non tu ne peux pas avoir un /boot chiffré sur une machine EFI à cause de l’EFI

Le tuto que tu as pris :slight_smile:

#29

Je ne conteste pas que ça peut marcher (je l’ai fait aussi) mais seulement que c’est « sans souci ».
Tu as mis /boot/efi dans un ensemble RAID. Cela pose deux problèmes :

  1. L’amorçage UEFI ne supporte pas le format du RAID logiciel de Linux. Il ne supporte qu’une partition FAT normale. Pour faire passer une partition membre RAID pour une partition EFI normale, il faut :
  • que ce soit du RAID 1 « miroir ». Tout autre type de RAID est incompatible.
  • que l’ensemble RAID soit en version 0.90 (obsolète) ou 1.0 afin que les métadonnées RAID soit placées à la fin des membres RAID et ne gênent pas. Or par défaut un ensemble RAID est créé en version 1.2 avec les métadonnées au début, ce qui empêche d’utiliser les partitions comme des partitions normales non RAID, et ça ne peut pas se changer sans détruire l’ensmble RAID et son contenu. Il faut donc créer l’ensemble RAID manuellement avec mdadm et l’option --metadata=1.0.
  • Que les partition aient le type « EFI » et non le type « RAID ».
  1. grub-install ne peut pas enregistrer GRUB dans les variables de boot EFI si /boot/efi n’est pas une partition normale. Il faut donc soit créer les variables de boot EFI (une pour chaque partition) à la main avec efibootmgr, soit ne pas utiliser de variable de boot EFI et installer GRUB dans le « chemin de support amovible » de la « partition » EFI. Je privilégie la seconde approche, plus sûre à mon avis car ne reposant pas sur les variables de boot EFI que je considère comme peu fiables.

Je vais te décevoir : ce n’est ni nécessaire ni suffisant. N’oublie pas que GRUB lui-même qui se trouve dans la partition EFI ne peut pas être chiffré. On peut donc lui faire charger un autre noyau (qui doit être signé si le secure boot est activé) ou initramfs (non vérifié par même avec le secure boot).

#30

Je m’apprêtais à écrire quand une notif m’a signalé ta réponse :cry:

Je me disais que j’allais me lancer dans l’install avec boot legacy mais finalement au niveau que je recherche, /boot chiffré ou non c’est la même car sans /boot chiffré j’y étais arrivé
là où je me suis mis dans le pétrin c’est lorsque j’ai voulu ajouter au démarrage le montage du 3e RAID qui ne sert que de stockage sans OS qui lui aussi est chiffré

je veux être sûr qu’à ma mort on ne retrouvera pas mes sex-tape sur mon serveur :yum:
Plaisanterie mise à part
Mon objectif est de transférer mon actuel nextcloud qui est sur une autre machine qui n’a pas la même config que celle-ci et sur laquelle je me suis contenté d’installer proxmox et chiffrer les VM mais c’est la croix et la bannière à chaque nécessité de reboot d’une VM (pb de clavier US-FR notamment)
je voulais monter d’un cran la sécurité ou la protection de mes données et me faciliter la vie sur le long terme…

en fin de compte retour à la case départ mais cette fois sans oublier crypttab au moment de l’ ajout de mon espace de « datas » pour le montage au boot.

Merci à vous :grinning:

#31

La sécurité implique de se compliquer la vie, on ne peut pas la simplifier avec.
Le chiffrage d’un disque c’est uniquement pour le cas où quelqu’un récupère le disque. Çà n’a pas d’impact sur l’accès distant.
Personnellement les seules machines chiffrées sont des VM qui ne sont jamais online. Je les allume quand j’en ai besoin je les éteint ensuite. Donc quelqu’un ayant accès à celle-ci devra d’abord avoir accès au Host, ensuite il devra pouvoir dechiffrer et c’est là que son problème commence, il n’aura pas le mot de passe qui fait plus de 20 caractères. De plus la machine n’etant pas fonctionnellement necessaire d’etre accessible à distance, il ne pourra pas y acceder à distance non plus.

J’ajouterais que pour sécuriser vraiment cela necessite du matériel, comme des équivalent des puces titan sur les smartphone.