Avkodning av LUKS-container vid systemstart

God dag, god kväll allihopa! Det här inlägget kommer att vara användbart för dem som använder LUKS-datakryptering och vill avkoda diskar under Linux (Debian, Ubuntu) vid avkodningen av root-partitionen. Och sådan information har jag inte kunnat hitta på internet.

Nyligen, med det ökande antalet diskar i hyllorna, stötte jag på problemet med avkodning av diskar med hjälp av den mer än kända metoden genom /etc/crypttab. Jag identifierar personligen flera problem med att använda denna metod, nämligen att filen läses endast efter att root-partitionen har laddats (mount), vilket negativt påverkar importen av ZFS, särskilt om de har skapats från partitioner på *_crypt-enheten, eller mdadm RAID som också byggdes från partitioner. Vi vet ju alla att man kan använda parted på LUKS-containrar? Och det finns också problemet med tidig start av andra tjänster när inte matriserna är klara, men använda något redan måste vara klart (jag arbetar med klusterbaserad Proxmox VE 5.x och ZFS över iSCSI).

Lite om ZFS över iSCSIiSCSI fungerar för mig genom LIO, och när iscsi-targeten startar och inte ser ZVOL-enheter, tar den helt enkelt bort dem från konfigurationen, vilket gör det omöjligt för gästsysten att starta. Därför antingen återställning av JSON-filens säkerhetskopia, eller manuell tilläggning av enheter med identifierarna för varje VM, vilket är en mardröm när man har tiotals sådana maskiner och i konfigurationen av varje mer än 1 disk.

Och den andra frågan som jag kommer att ta upp är hur man genomför avkodningen (detta är en nyckelpunkt i artikeln). Och om detta kommer vi att diskutera nedan, kom och titta!

Ofast används nyckelfiler (naturligtvis först tillagda i slotten med kommandot — cryptsetup luksAddKey), eller i sällsynta undantag (det finns mycket lite information på ryskspråkiga internet) — skriptet decrypt_derived, som ligger i /lib/cryptsetup/script/ (självklart finns det också andra metoder, men jag använde just dessa två, vilket utgör grunden för artikeln). Jag strävade också efter en helt autonom aktivering efter omstarter, utan någon ytterligare kommandon i konsolen, så att allt skulle "flyga" direkt. Så varför vänta? —

Låt oss börja!

Vi föreställer oss ett system, till exempel Debian, installerat på kryptodelen sda3_crypt och ett dussin diskar redo att krypteras och skapa vad som helst. Vi har en nyckelfras (passphrase) för att låsa upp sda3_crypt, och från denna partition kommer vi att ta "hashen" av lösenordet på det körande (avkrypterade) systemet och lägga till det på de andra diskarna. Allt är enkelt, vi kör följande i konsolen:

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

där X är våra diskar, partitioner osv.

Efter att ha krypterat diskarna med "hashen" av vår nyckelfras, behöver vi veta UUID eller ID - beroende på vad man är van vid. Vi tar uppgifter från /dev/disk/by-uuid och by-id respektive.

Nästa steg är att förbereda filer och miniskript för att arbeta med de funktioner vi behöver, låt oss börja:

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/

vidare

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

Innehållet i ../decrypt

#!/bin/sh

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

vidare

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

Innehållet i ../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"

lite mer

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

Innehållet i ../partprobe

#!/bin/sh

$DESTDIR/bin/partprobe

och sist, innan update-initramfs, måste vi redigera filen /etc/initramfs-tools/scripts/local-top/cryptroot, med början från rad ~360, koden nedan

Original

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

och konverterar den till detta format

Redigerad

                # 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

Observera att vi här kan använda antingen UUID eller ID. Det viktigaste är att de nödvändiga drivrutinerna för HDD/SSD-enheterna är tillagda i /etc/initramfs-tools/modules. För att ta reda på vilken drivrutin som används kan man använda kommandot udevadm info -a -n /dev/sdX | egrep 'looking|DRIVER'.

Nu när vi är klara och alla filer är på plats kör vi update-initramfs -u -k all -v, i loggningen ska det inte finnas några fel i körningen av våra skript. Vi startar om, anger nyckelfrasen och väntar en stund, beroende på antalet diskar. Därefter startar systemet och i slutskedet av starten, efter "monteringen" av root-partitionen, kommer kommandot partprobe att köras — det kommer att hitta och koppla alla skapade partitioner på LUKS-enheter och alla arrayer, oavsett om det är ZFS eller mdadm, kommer att sättas ihop utan problem! Och allt detta innan de grundläggande tjänsterna och servrarna som behöver dessa diskar/arrayer. update1

: Hurhar jag märkt AEP , denna metod fungerar endast för LUKS1.Windows, PowerShell och långa sökvägar

Källa: habr.com