Goede dag en nacht allemaal! Dit bericht is handig voor degenen die LUKS-gegevenscodering gebruiken en schijven willen decoderen onder Linux (Debian, Ubuntu) op stadia van het decoderen van de rootpartitie. En ik kon dergelijke informatie niet op internet vinden.
Meer recent, met de toename van het aantal schijven in de schappen, kwam ik het probleem tegen om schijven te decoderen met behulp van de meer dan bekende methode via /etc/crypttab. Persoonlijk belicht ik enkele problemen bij het gebruik van deze methode, namelijk dat het bestand wordt gelezen alleen na het laden (mounten) van de rootpartitie, wat een negatieve invloed heeft op ZFS-imports, met name als ze zijn gebouwd op basis van partities op het *_crypt-apparaat, of ook op mdadm-raids die zijn gebouwd op basis van partities. We weten allemaal dat je parted op LUKS-containers kunt gebruiken, toch? En ook het probleem van de vroege start van andere diensten, wanneer er nog geen arrays zijn, maar te gebruiken Ik heb al iets nodig (ik werk met geclusterde Proxmox VE 5.x en ZFS via iSCSI).
Een beetje over ZFSoverISCSIiSCSI werkt voor mij via LIO, en in feite, wanneer het iscsi-doel start en geen ZVOL-apparaten ziet, verwijdert het ze gewoon uit de configuratie, waardoor gastsystemen niet kunnen opstarten. Vandaar ofwel het herstellen van een json-bestandsback-up, ofwel het handmatig toevoegen van apparaten met identifiers voor elke VM, wat gewoon verschrikkelijk is als er tientallen van dergelijke machines zijn en elke configuratie meer dan 1 schijf heeft.
En de tweede vraag die ik zal overwegen, is hoe te decoderen (dit is het belangrijkste punt van het artikel). En we zullen hier hieronder over praten, ga onder de knip!
Meestal wordt op internet een sleutelbestand gebruikt (zelf eerder aan de sleuf toegevoegd door de opdracht - cryptsetup luksAddKey), of in zeldzame uitzonderingen (op het Russischtalige internet is er zeer weinig informatie) - het decrypt_derived script bevindt zich in /lib/cryptsetup/script/ (er zijn natuurlijk andere manieren, maar ik heb deze twee gebruikt, die de basis van het artikel vormden). Ik streefde ook naar volledige autonome opname na opnieuw opstarten, zonder extra commando's in de console, zodat alles in één keer voor mij zou "vliegen". Daarom, waarom wachten? β
Laten we beginnen!
Laten we aannemen dat een systeem, zoals Debian, is geΓ―nstalleerd op een sda3_crypt cryptopartitie en een dozijn schijven klaar om te worden gecodeerd en gemaakt naar hartenlust. We hebben een wachtwoordzin (wachtwoordzin) om sda3_crypt te ontgrendelen, en vanaf deze partitie zullen we de "hash" van het wachtwoord op het draaiende (gedecodeerde) systeem verwijderen en toevoegen aan de rest van de schijven. Alles is elementair, in de console voeren we uit:
/lib/cryptsetup/scripts/decrypt_derived sda3_crypt | cryptsetup luksFormat /dev/sdXwaar X onze schijven, partities, etc. is.
Na het versleutelen van de schijven met een "hash" van onze wachtwoordzin, moet u de UUID of ID achterhalen - afhankelijk van wie wat gewend is en wat. We nemen gegevens van respectievelijk /dev/disk/by-uuid en by-id.
De volgende stap is het voorbereiden van bestanden en miniscripts voor de functies die we nodig hebben om te werken, laten we doorgaan:
cp -p /usr/share/initramfs-tools/hooks/cryptroot /etc/initramfs-tools/hooks/
cp -p /usr/share/initramfs-tools/scripts/local-top/cryptroot /etc/initramfs-tools/scripts/local-top/verder
touch /etc/initramfs-tools/hooks/decrypt && chmod +x /etc/initramfs-tools/hooks/decryptInhoud van ../decrypt
#!/bin/sh
cp -p /lib/cryptsetup/scripts/decrypt_derived "$DESTDIR/bin/decrypt_derived"verder
touch /etc/initramfs-tools/hooks/partcopy && chmod +x /etc/initramfs-tools/hooks/partcopyDe inhoud van ../partcopy
#!/bin/sh
cp -p /sbin/partprobe "$DESTDIR/bin/partprobe"
cp -p /lib/x86_64-linux-gnu/libparted.so.2 "$DESTDIR/lib/x86_64-linux-gnu/libparted.so.2"
cp -p /lib/x86_64-linux-gnu/libreadline.so.7 "$DESTDIR/lib/x86_64-linux-gnu/libreadline.so.7"wat meer
touch /etc/initramfs-tools/scripts/local-bottom/partprobe && chmod +x /etc/initramfs-tools/scripts/local-bottom/partprobeInhoud ../deeltaster
#!/bin/sh
$DESTDIR/bin/partprobeen als laatste, voor update-initramfs, moet je het bestand /etc/initramfs-tools/scripts/local-top/cryptroot bewerken, beginnend vanaf regel ~360, codefragment hieronder
Origineel
# decrease $count by 1, apparently last try was successful.
count=$(( $count - 1 ))
message "cryptsetup ($crypttarget): set up successfully"
break
en breng het naar dit formulier
Bewerkt
# decrease $count by 1, apparently last try was successful.
count=$(( $count - 1 ))
/bin/decrypt_derived $crypttarget | cryptsetup luksOpen /dev/disk/by-uuid/ *CRYPT_MAP*
/bin/decrypt_derived $crypttarget | cryptsetup luksOpen /dev/disk/by-id/ *CRYPT_MAP*
message "cryptsetup ($crypttarget): set up successfully"
breakMerk op dat UUID of ID hier kan worden gebruikt. Het belangrijkste is dat de benodigde stuurprogramma's voor HDD/SSD-apparaten worden toegevoegd aan /etc/initramfs-tools/modules. Met de opdracht kunt u achterhalen welke driver wordt gebruikt udevadm info -a -n /dev/sdX | egrep 'op zoek naar | BESTUURDER'.
Nu we klaar zijn en alle bestanden aanwezig zijn, voer je uit update-initramfs -u -k all -v, bij het loggen moet niet zijn uitvoeringsfouten van onze scripts. We herstarten, voeren de wachtwoordzin in en wachten een beetje, afhankelijk van het aantal schijven. Vervolgens start het systeem en in de laatste fase van de lancering, namelijk na het "mounten" van de rootpartitie, wordt de opdracht partprobe uitgevoerd - het zal alle gemaakte partities op LUKS-apparaten en alle arrays vinden en ophalen, of het nu ZFS of mdadm, wordt zonder problemen gemonteerd! En dit alles voor het laden kernservices en services die deze schijven/arrays nodig hebben.
update1: Hoe , werkt deze methode alleen voor LUKS1.
Bron: www.habr.com