Dekryptering af en LUKS-beholder ved systemstart

God dag og nat alle sammen! Dette indlæg vil være nyttigt for dem, der bruger LUKS datakryptering og ønsker at dekryptere diske under Linux (Debian, Ubuntu) på stadier af dekryptering af rodpartitionen. Og jeg kunne ikke finde sådanne oplysninger på internettet.

For nylig, med stigningen i antallet af diske på hylderne, stødte jeg på problemet med at dekryptere diske ved hjælp af den mere end velkendte metode gennem /etc/crypttab. Personligt fremhæver jeg et par problemer med at bruge denne metode, nemlig at filen bliver læst først efter indlæsning (montering) af rodpartitionen, hvilket påvirker ZFS-importer negativt, især hvis de blev bygget fra partitioner på *_crypt-enheden, eller mdadm-raids også bygget fra partitioner. Vi ved alle, at du kan bruge parted på LUKS containere, ikke? Og også problemet med den tidlige start af andre tjenester, når der ikke er nogen arrays endnu, men at bruge Jeg har allerede brug for noget (jeg arbejder med clustered Proxmox VE 5.x og ZFS over iSCSI).

Lidt om ZFSoverISCSIiSCSI fungerer for mig gennem LIO, og faktisk, når iscsi-målet starter og ikke ser ZVOL-enheder, fjerner det dem simpelthen fra konfigurationen, hvilket forhindrer gæstesystemer i at starte. Derfor enten gendannelse af en backup af en json-fil eller manuelt tilføjelse af enheder med identifikatorer for hver VM, hvilket simpelthen er forfærdeligt, når der er snesevis af sådanne maskiner, og hver konfiguration har mere end 1 disk.

Og det andet spørgsmål, som jeg vil overveje, er, hvordan man dekrypterer (dette er hovedpunktet i artiklen). Og vi vil tale om dette nedenfor, gå under skæringen!

Oftest bruges en nøglefil på internettet (selv tilføjet til slot før dette ved kommandoen - cryptsetup luksAddKey), eller i sjældne undtagelser (på det russisksprogede internet er der meget lidt information) - det decrypt_derived script placeret i /lib/cryptsetup/script/ (selvfølgelig er der andre måder, men jeg brugte disse to, som dannede grundlaget for artiklen). Jeg stræbte også efter fuld autonom inklusion efter genstart uden yderligere kommandoer i konsollen, så alt ville "flyve op" for mig på én gang. Derfor, hvorfor vente? —

Lad os komme i gang!

Lad os antage, at et system som Debian er installeret på en sda3_crypt kryptopartition og et dusin diske klar til at blive krypteret og oprettet efter dit hjertes lyst. Vi har en adgangssætning (passphrase) til at låse op for sda3_crypt, og det er fra denne partition, vi vil fjerne "hash" fra adgangskoden på det kørende (dekrypterede) system og tilføje det til resten af ​​diskene. Alt er elementært, i konsollen udfører vi:

/lib/cryptsetup/scripts/decrypt_derived sda3_crypt | cryptsetup luksFormat /dev/sdX

hvor X er vores diske, partitioner osv.

Efter at have krypteret diskene med en "hash" fra vores adgangssætning, skal du finde ud af UUID eller ID - alt efter hvem der er vant til hvad og hvad. Vi tager data fra henholdsvis /dev/disk/by-uuid og by-id.

Det næste trin er at forberede filer og mini-scripts til de funktioner, vi skal bruge for at fungere, lad os fortsætte:

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/

yderligere

touch /etc/initramfs-tools/hooks/decrypt && chmod +x /etc/initramfs-tools/hooks/decrypt

Indhold af ../dekryptere

#!/bin/sh

cp -p /lib/cryptsetup/scripts/decrypt_derived "$DESTDIR/bin/decrypt_derived"

yderligere

touch /etc/initramfs-tools/hooks/partcopy && chmod +x /etc/initramfs-tools/hooks/partcopy

Indholdet af ../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"

En smule mere

touch /etc/initramfs-tools/scripts/local-bottom/partprobe && chmod +x /etc/initramfs-tools/scripts/local-bottom/partprobe

Indhold ../partprobe

#!/bin/sh

$DESTDIR/bin/partprobe

og sidst, før update-initramfs, skal du redigere filen /etc/initramfs-tools/scripts/local-top/cryptroot, startende fra linje ~360, kodestykke nedenfor

Original

                # decrease $count by 1, apparently last try was successful.
                count=$(( $count - 1 ))
                
                message "cryptsetup ($crypttarget): set up successfully"
                break

og bringe det til denne form

Redigeret

                # 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"
                break

Bemærk, at enten UUID eller ID kan bruges her. Det vigtigste er, at de nødvendige drivere til HDD / SSD-enheder tilføjes til /etc/initramfs-tools/modules. Du kan finde ud af, hvilken driver der bruges med kommandoen udevadm info -a -n /dev/sdX | egrep 'søger|DRIVER'.

Nu hvor vi er færdige, og alle filerne er på plads, skal du køre update-initramfs -u -k alle -v, i logning må ikke være udførelsesfejl af vores scripts. Vi genstarter, indtaster adgangssætningen og venter lidt, afhængigt af antallet af diske. Dernæst vil systemet starte, og på det sidste trin af lanceringen, nemlig efter at have "monteret" rodpartitionen, vil partprobe-kommandoen blive udført - den vil finde og hente alle oprettede partitioner på LUKS-enheder og eventuelle arrays, det være sig ZFS eller mdadm, vil blive samlet uden problemer! Og alt dette før lastning kernetjenester og tjenester, der har brug for disse diske/arrays.

opdatering1: Hvordan bemærket AEP, denne metode virker kun for LUKS1.

Kilde: www.habr.com