Dotaz: debian 13 boot s luks keyfile na usb flashdisku, fallback password ne

[pavele]

Mám nainstalovaný Debian 13.

První diskový oddíl je nešifrovaný /boot.

Druhý diskový oddíl je šifrovaný pomocí luks.

Při instalaci systému jsem nastavil přístupové heslo k luks. Po restartu se systém zeptá na heslo, to zadám a systém najede.

Chci mít možnost automatického přihlášení/odemknutí luks pomocí klíče uloženého na flashdisku a fallback pomocí hesla, když nebude fleška k dispozici. Upravil jsem tedy /etc/crypttab, aby vypadal nějak takto:

dm_crypt-0 UUID=80edd8a0-51ef-43ac-b2c1-62ababd1809a /dev/disk/by-uuid/09179c27-02cd-43a8-a59b-fd6eb8ef9e32:/luks-keyfile:30 luks,keyscript=passdev

Po restartu a vložení USB flešky se luks odemkne a systém najede. Bohužel bez flashdisku nedojde k fallbacku na prompt s heslem.

Zkusil jsem přidat do souboru crypttab directivu keyfile-timeout=10. Při update-initramfs mi vyleze chybová hláška, že parametr keyfile-timeout je neznámý.

Co s tím?

Odpovědi

[pavele]

Příloha:

• Snímek obrazovky_2026-02-03_18-06-22.jpg (84817 bytů)

Přidávám fotku - boot bez flashdisku.

[X]

Jen podle oka ID v logu jsou uplne jina nez mas v crypttab. Narazil jsem na podobny problem, ale zda to pomuze nevim.

[pavele]

Pardon, skutecny soubor /etc/crypttab

# Funguje jen s heslem

#sda2_crypt UUID=bba1f061-d95f-4a86-a4b3-73978d296483 none luks,discard,x-initrd.attach

# Funguje jen s klicem

sda2_crypt UUID=bba1f061-d95f-4a86-a4b3-73978d296483 /dev/disk/by-uuid/005B-2A9F:/keyfile:30 luks,keyscript=passdev

Muzu si vybrat bud jeden nebo druhy,u toho s klicem nefunguje fallback na heslo.

[X]

Pokus 1:

sda2_crypt UUID=bba1f061-d95f-4a86-a4b3-73978d296483 /dev/disk/by-uuid/005B-2A9F:/keyfile:30 luks,keyscript=/lib/cryptsetup/scripts/passdev

Pokus 2:

sda2_crypt UUID=bba1f061-d95f-4a86-a4b3-73978d296483 /dev/disk/by-uuid/005B-2A9F:/keyfile:30 luks,keyscript=/lib/cryptsetup/scripts/passdev,initramfs

src,src,src

[X]

update-initramfs -uv

[pavele]

Tak nic. Už mi zbývá asi jen zkusit vlastní skript místo /lib/cryptsetup/scripts/passdev.

[pavele]

ChatGPT řekl:

Jo, tohle je klasický problém passdev – ten skript je navržený tak, že když selže čtení klíče, už nevyvolá interaktivní dotaz, takže se k passphrase nikdy nedostaneš. Řešení je vlastní keyscript, který:

zkusí najít USB a načíst keyfile

pokud se to nepovede → vrátí nenulový návratový kód, aby cryptsetup spadl zpět na interaktivní prompt

[Andrej]

Což je známo už 12+ let. 12 let stáří představuje v případě Debianu nejnovější „bleeding-edge“ „verzi“, což znamená, že i 12+ let staré informace by ještě mohly být použitelné.

Každopádně: TPM2 prostě funguje. Prapodivné triky s flashkami nejsou zrovna ideální.

[Max]

To je divný, keyfile-timeout by měl být dostupný už celkem dlouho.

Jak odemykáš luks? Přes encrypt? Nebo mnohem lépe přes sd-encrypt? Pokud přes encrypt, doporučuji switch na sd-encrypt a zkusit použít pak parametry v rámci něho, tj.

rd.luks.key=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=/path/to/keyfile:UUID=ZZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ

a timeout

rd.luks.options=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=keyfile-timeout=10s

Tj. místo kernel parametru GRUB_CMDLINE_LINUX="cryptdevice=UUID=d3ab738e-3a7b-4fca-96bc-32d01a3c3d38:system" použít:

GRUB_CMDLINE_LINUX="rd.luks.name=d3ab738e-3a7b-4fca-96bc-32d01a3c3d38=system rd.luks.name=f9a3b527-479a-4600-8007-036ab55a5262=system2... rd.luks.key=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=/path/to/keyfile:UUID=ZZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ rd.luks.options=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=keyfile-timeout=10s"

Aspoň podobně to jedu v ArchLinux, Debian 12 údajně potřeboval přejít na dracut, ale co tak koukám, tak Debian 13 / Trixie by podporu pro toto mělo mít.
Zdar Max

[okurka]

Jak odemykáš luks? Přes encrypt? Nebo mnohem lépe přes sd-encrypt?

jen reklama?

[pavele]

Provedl jsem klasickou instalaci Debianu 13 s tím, že mám samostatně /boot a samostatně diskový oddíl sda2 zašifrovaný luks. Po instalaci bez problémů odemknu luks pomocí hesla, systém najede.

Co chci: Použít pro odemknutí klíč, umístěný na USB flashdisku a v případě, že flashdisk není přítomný, tak fallback na přihlášení heslem. Opravte mě a Al, jestli je to možné s použitím tohoto řádku v /etc/crypttab s volbou "keyscript=passdev:

sda2_crypt UUID=bba1f061-d95f-4a86-a4b3-73978d296483 /dev/disk/by-uuid/005B-2A9F:/keyfile:30 luks,keyscript=passdev

[Peter Golis]

Ako veľmi bude tá flashka chránená voči odcudzeniu, bude kryptovaná alebo sa bude jednať o falošný pocit bezpečia? Pýtam sa pre kamaráta.

Radšej by som zainvestoval do napr. Yabakey alebo niečoho podobného, keď už TPM vyžaduje SB ...

[pavele]

S Yubikey budo mít úplně stejný problém s fallback na heslo jako s flashdiskem.

[pavele]

Pokud dám do /etc/crypttab místo passdev cestu ke svému skriptu, tak:

- pokud je flashdisk vložený, vše proběhne v pořádku, luks se odemkne

- Bez flashdisku můj skript skončí s exit 1 a měl by následovat fallback na heslo, ale skript je okamžitě znovu nahozen (proč?). Pokud dám jako parametr crypttab directivu keyfile-timeout=10, při update-initramfs mi vyleze chybová hláška, že parametr keyfile-timeout je neznámý.

[X]

Je to trochu slozitejsi:

Please note that there are several independent cryptsetup wrappers with their own crypttab format. This manpage covers Debian's implementation for initramfs scripts and SysVinit init scripts. systemd brings its own crypttab implementation. We try to cover the differences between the systemd and our implementation in this manpage,

[Peter Golis]

Používam TPM s automatickým fallbackom na zadanie hesla, a funguje to spoľahlivo.

Ale je pravda že nepoužívam debian, a dodané backdoorové kľúče som vymazal.

[RealJ]

a nahral jsi si jako Izak cinske a ruske klice? Se ptam pro kamarada...

[Peter Golis]

Kľudne môžeš povedať kamarátovi že nie. Po tom ako som si vymazal všetky dodané kľúče, tak som si nahral len tie mnou lokálne vygenerované.

[Max]

A teď to zkus na stroji, kde je dual boot s windows :D.
Zdar Max

[Peter Golis]

Ty pre nich pracuješ že robíš takýto zbytočný nábor?

[ewew]

Je nutné použiť správny syntax. Keďže debian používa systemd-cryptsetup nie pôvodný cryptsetup. Z tohto dôvodu sa líši syntax crypttabu.

dm_crypt-0 UUID=80edd8a0-51ef-43ac-b2c1-62ababd1809a /luks-keyfile:UUID=09179c27-02cd-43a8-a59b-fd6eb8ef9e32 luks,keyfile-timeout=10 Tento syntax mi fungoval v qemu s debianom 14. Odpojenie USB s kľúčom vyvolalo požiadavku na heslo k šifrovanému oddielu. Netestoval som to voči dynamickej detekcii USB. V qemu bolo usb definované cez usb-storagem, nie scsi-hd.

[pavele]

Debian 14 bude mít asi jinou syntax než Debian 13.

Mám už funkční skript, ale Debian mi trochu háže klacky pod nohy, protože /bin/sh je v Debianu dash = /bin/dash, a v něm nefungují všechny věci jako v Bashi.

[Max]

1) Vždy můžeš volat bash, prostě do scriptu dáš #!/bin/bash
2) výše uvedené s rd.luks... nefunguje? Mělo by být v Debian13
Zdar Max

[pavele]

Příloha:

• odemknuti-klic-na-flashdisku-nebo-heslo.jpg (40150 bytů)

Už to jede, ale skript je ve vývoji.

[ewew]

VM s debian 13 ide presne tak isto ako v debian 14. Problém je odlišnosťach v cryptsetup a systemd-cryptsetup.

[Max]

Jsem myslel, že Debian 13 má už také systemd-cryptsetup?
Třeba na Archu jsem na systemd-cryptsetup přešel už dávno, protože oproti staršímu cryptsetup umí otevřít všechny volume pomocí jednou zadaného hesla a nikdo se nedrbal s opatchováním staršího cryptsetup, aby to uměl také.
Zdar Max

[jejda]

To abys nemusel ručně datlovat hesla ke všem diskům se nastavuje v /etc/crypttab přecházet kvůli tomu na systemd-cryptsetup není potřeba.

[Max]

To mi nefungovalo a dočetl jsem se, že to je kvůli nepodpoře ze strany starší implementace. Řešil jsem to ale v rámci ArchLinux, viz "Using_encrypt_hook".
Zdar Max

[jejda]

Taky mám archlinux a cryptsetup verze 2.8.4 ale mám nešifrovaný oddíl /boot a žádný LVM ani RAID nepoužívám. Ty zbývající disky se odemykají automaticky ale až potom co je hlavní filesystém / čitelný. V /etc/crypttab mám něco takového:

disk2   UUID=d77df71a-c37d-4c5e-bfb6-9c48a62354ee       /root/dpw       luks,nofail
disk3   UUID=64a0fc06-d025-483c-b368-51383150b4d0       /root/dpw       luks,nofail
disk4   UUID=f17d3583-574b-4214-af4c-001f8519fe25       /root/dpw       luks,nofail

Soubor /root/dpw má práva 600 a obsahuje heslo jako holý text bez newline. Mám to tak už léta a funguje to bez problémů. Nedávno jsem instaloval arch na jeden novější počítač a zkusil jsem místo grubu nasadit sd-boot a sd-encrypt a funguje to taky. Jenom je potřeba změnit ty volby pro kernel. Místo starého:

cryptdevice=UUID=a332c454-4fa1-4306-a82d-3334b46f10c5:sysdisk

se to zadává jako:

rd.luks.name=a332c454-4fa1-4306-a82d-3334b46f10c5=sysdisk

Furt jakési novoty Zrovna včera jsem se kdesi dočetl, že když máš v počítači místo biosu uefi, tak už žádný bootloader není potřeba a uefi prý umí natáhnout linux bez něho Otázka ale je, jestli by takový disk naběhl když by se zapojil do jinačího PC s jinačím uefi. Pokud ne, bylo by to teda pěkně naprd.

[Peter Golis]

Furt jakési novoty Zrovna včera jsem se kdesi dočetl, že když máš v počítači místo biosu uefi, tak už žádný bootloader není potřeba a uefi prý umí natáhnout linux bez něho Otázka ale je, jestli by takový disk naběhl když by se zapojil do jinačího PC s jinačím uefi. Pokud ne, bylo by to teda pěkně naprd.

To zavádzanie Linuxu (kernel+initrd) bez boot loadera v UEFI sa obvykle deje pomocou UKIFY čo je vo výsledku UEFI binárka obsahujúca kernel s initrd. Takže by v inom počítači stačilo vybrať namiesto štartu zavádzača štart daného UKIFY jadra. V prípade UEFI Secure Boot musí byť to UKIFY navyše podpísané kľúčom ktorý ti tá doska akceptuje.

[pavele]

Jsem myslel, že Debian 13 má už také systemd-cryptsetup?
Třeba na Archu jsem na systemd-cryptsetup přešel už dávno, protože oproti staršímu cryptsetup umí otevřít všechny volume pomocí jednou zadaného hesla a nikdo se nedrbal s opatchováním staršího cryptsetup, aby to uměl také.
Zdar Max

Odemykání pomocí hesla, v /etc/crypttab mám:

sda2_crypt UUID=bba1f061-d95f-4a86-a4b3-73978d296483 none luks,discard,x-initrd.attach

Odemykání pomocí USB klíče, v /etc/crypttab mám:

sda2_crypt UUID=bba1f061-d95f-4a86-a4b3-73978d296483 /dev/disk/by-uuid/005B-2A9F:/keyfile:15 luks,keyscript=passdev

Odemykání pomocí USB klíče, fallback na heslo, v /etc/crypttab mám:

sda2_crypt UUID=bba1f061-d95f-4a86-a4b3-73978d296483 none luks,keyscript=/usr/local/sbin/keyscript-usb-or-passphrase1,initramfs,tries=5

 

Mohl by ses trochu rozepsat, jak odemknout kořen / pomocí systemd.cryptsetup pomocí klíče nebo hesla?

/boot mám nešifrovaný samostatný, kořen / mám šifrovaný luks.

[ewew]

Příloha:

• desktop_screen_20260208.jpg (459198 bytů)

Prikladám screen. V jednom VM je položka zakomentovaná. Posledný riadok /etc/crypttab je rovnaký aj v debian 13 a debian 14.

[pavele]

Prikladám screen. V jednom VM je položka zakomentovaná. Posledný riadok /etc/crypttab je rovnaký aj v debian 13 a debian 14.

Problém je odlišnostech v cryptsetup a systemd-cryptsetup.

Ve třetím sloupci souboru crypttab má být.:

/dev/disk/by-uuid/UUID-USB:/keyfile ......... cryptsetup

/keyfile:UUID=UUID-USB .......... systemd-cryptsetup

Prostě někdo, kdo tvoří systemd rozhodl, že nebude dodržovat konvenci cryptsetup a udělá si to po svém.