It ûntsiferjen fan in LUKS-container by systeemstarttiid

Goeie dei en nacht allegearre! Dizze post sil nuttich wêze foar dyjingen dy't LUKS-gegevensfersifering brûke en skiven wolle ûntsiferje ûnder Linux (Debian, Ubuntu) op stadia fan it ûntsiferjen fan de root-partysje. En ik koe net fine sokke ynformaasje op it ynternet.

Mear resint, mei de tanimming fan it oantal skiven yn 'e planken, rûn ik yn it probleem fan it ûntsiferjen fan skiven mei de mear dan bekende metoade fia /etc/crypttab. Persoanlik markearje ik in pear problemen mei it brûken fan dizze metoade, nammentlik dat it bestân wurdt lêzen pas nei it laden (mount) de root partition, dy't negatyf beynfloedet ZFS-ymporten, benammen as se binne boud fan partysjes op it *_crypt-apparaat, of mdadm-raids boud fan partysjes ek. Wy witte allegear dat jo skieden kinne brûke op LUKS-konteners, krekt? En ek it probleem fan 'e iere start fan oare tsjinsten, as der noch gjin arrays binne, mar brûke Ik haw al wat nedich (Ik wurkje mei klustere Proxmox VE 5.x en ZFS oer iSCSI).

In bytsje oer ZFSoverISCSIiSCSI wurket foar my fia LIO, en yn feite, as it iscsi-doel begjint en ZVOL-apparaten net sjogge, ferwiderje se gewoan út 'e konfiguraasje, wat foarkomt dat gastsystemen opstarten. Sadwaande, it herstellen fan in backup fan json-bestân, of it manuell tafoegjen fan apparaten mei identifiers foar elke VM, wat gewoan ferskriklik is as d'r tsientallen sokke masines binne en elke konfiguraasje mear dan 1 skiif hat.

En de twadde fraach dy't ik sil beskôgje is hoe te ûntsiferjen (dit is it wichtichste punt fan it artikel). En wy sille it hjirûnder oer prate, gean ûnder de besuniging!

Meastentiids wurdt op it ynternet in kaaibestân brûkt (sels taheakke oan it slot dêrfoar troch it kommando - cryptsetup luksAddKey), of yn seldsume útsûnderings (op it Russysktalige ynternet is d'r heul min ynformaasje) - it decrypt_derived skript leit yn /lib/cryptsetup/script/ (fansels binne d'r oare manieren, mar ik brûkte dizze twa, dy't de basis fan it artikel foarmen). Ik stride ek foar folsleine autonome ynklúzje nei herstarten, sûnder ekstra kommando's yn 'e konsole, sadat alles tagelyk foar my soe "fleane". Dêrom, wêrom wachtsje? -

Litte wy begjinne!

Litte wy oannimme dat in systeem, lykas Debian, is ynstalleare op in sda3_crypt-krypto-partysje en in tsiental skiven klear om te fersifere en makke nei de ynhâld fan jo hert. Wy hawwe in passphrase (passphrase) om sda3_crypt te ûntsluten, en it is fan dizze dieling dat wy de "hash" sille fuortsmite fan it wachtwurd op it rinnende (ûntsifere) systeem en it tafoegje oan 'e rest fan' e skiven. Alles is elemintêr, yn 'e konsole útfiere wy:

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

wêr't X ús skiven, partysjes, ensfh.

Nei it fersiferjen fan de skiven mei in "hash" fan ús passphrase, moatte jo de UUID of ID fine - ôfhinklik fan wa't wend is oan wat en wat. Wy nimme gegevens fan respektivelik /dev/disk/by-uuid en by-id.

De folgjende stap is it tarieden fan bestannen en mini-skripts foar de funksjes dy't wy moatte wurkje, litte wy trochgean:

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/

fierder

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

Ynhâld fan ../decrypt

#!/bin/sh

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

fierder

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

De ynhâld fan ../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"

in bytsje mear

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

Ynhâld ../partprobe

#!/bin/sh

$DESTDIR/bin/partprobe

en as lêste, foar update-initramfs, moatte jo it /etc/initramfs-tools/scripts/local-top/cryptroot-bestân bewurkje, begjinnend fan rigel ~360, koadefragment hjirûnder

Oarspronklik

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

en bring it nei dizze foarm

Bewurke

                # 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

Tink derom dat UUID of ID hjir kinne wurde brûkt. It wichtichste is dat de nedige bestjoerders foar HDD / SSD-apparaten wurde tafoege oan /etc/initramfs-tools/modules. Jo kinne útfine hokker bestjoerder wurdt brûkt mei it kommando udevadm info -a -n /dev/sdX | egrep 'looking|DRIVER'.

No't wy klear binne en alle bestannen op it plak binne, rinne update-initramfs -u -k all -v, yn logging moat net wêze útfieringsflaters fan ús skripts. Wy rebootje, fier de passphrase yn en wachtsje in bytsje, ôfhinklik fan it oantal skiven. Dêrnei sil it systeem begjinne en yn 'e lêste faze fan lansearring, nammentlik nei it "mounten" fan de root-partysje, sil it partprobe-kommando wurde útfierd - it sil alle oanmakke partysjes op LUKS-apparaten en alle arrays fine en ophelje, itsij ZFS as mdadm, sil wurde gearstald sûnder problemen! En dit alles foar it laden core tsjinsten en tsjinsten dy't nedich dizze skiven / arrays.

fernijing 1:hoe opmurken AEP, dizze metoade wurket allinnich foar LUKS1.

Boarne: www.habr.com