You are not logged in.

#1 2025-01-19 16:09:05

neocat
Member
Registered: 2022-09-16
Posts: 25

[SOLVED] Can't use different keyslot for LUKS decryption in initramfs

I installed Arch using the archinstall script and chose full-disk encryption with two key options: passphrase and yubikey.
The problem is that when I boot into the system, I am prompted to tap the yubikey, not to enter the passphrase. But I want to be able to enter the passphrase when yubikey is not connected.
Is there a way to achieve this behavior?

I'm sure both options were applied successfully, because when I do `cryptsetup luksDump` I see two keyslots, and when I do `cryptsetup open --test-passphrase` I can unlock it with the passphrase

Last edited by neocat (2025-01-21 10:17:41)

Offline

#2 2025-01-19 19:42:27

libertepourmoi
Member
Registered: 2022-03-26
Posts: 16

Re: [SOLVED] Can't use different keyslot for LUKS decryption in initramfs

What is your kernel command line?

cat /proc/cmdline

AFAIK you can only configure one method to decrypt the disk on the command line. If the configured method fails and there are other keyslots, those are tried in a certain order, see man systemd-cryptsetup@.service. So if decryption with the yubikey fails, you should be presented a password prompt. This might mean that you have to wait for a timeout though.

Offline

#3 2025-01-20 10:32:12

neocat
Member
Registered: 2022-09-16
Posts: 25

Re: [SOLVED] Can't use different keyslot for LUKS decryption in initramfs

cat /proc/cmdline output

initrd=\initramfs-linux.img rd.luks.name=48ceea25-a9b5-426f-a538-3e9fe889afb5=root rd.luks.options=fido2-device=auto,password-echo=no root=/dev/mapper/root rw rootfstype=ext4

should I change the password-echo option to yes to be able to type the passphrase?

libertepourmoi wrote:

This might mean that you have to wait for a timeout though.

I noticed, that yubikey tap timeout is set to nolimit on boot. I guess I should add something to /proc/cmdline to have the timeout?

Last edited by neocat (2025-01-20 10:37:34)

Offline

#4 2025-01-20 11:51:53

nl6720
The Evil Wiki Admin
Registered: 2016-07-02
Posts: 714

Re: [SOLVED] Can't use different keyslot for LUKS decryption in initramfs

It looks like token-timeout= is the option you're looking for. Try adding it to rd.luks.options.

Offline

#5 2025-01-20 16:07:27

neocat
Member
Registered: 2022-09-16
Posts: 25

Re: [SOLVED] Can't use different keyslot for LUKS decryption in initramfs

Thanks! Now I can input the passphrase after the timeout.

I updated the /boot/loader/entries/linux.conf file with token-timeout= option so it looks like this now

title   Arch Linux (linux)
linux   /vmlinuz-linux
initrd  /initramfs-linux.img
options rd.luks.name=48ceea25-a9b5-426f-a538-3e9fe889afb5=root rd.luks.options=fido2-device=auto,token-timeout=15,password-echo=no root=/dev/mapper/root rw rootfstype=ext4

Is it ok or this file will be overwritten after the kernel update and I must change something else?

Offline

#6 2025-01-20 18:29:40

libertepourmoi
Member
Registered: 2022-03-26
Posts: 16

Re: [SOLVED] Can't use different keyslot for LUKS decryption in initramfs

That's ok, this file will not be overwritten.

Offline

#7 2025-01-22 19:06:01

archlynovice
Member
Registered: 2023-10-22
Posts: 32

Re: [SOLVED] Can't use different keyslot for LUKS decryption in initramfs

The thread is solved, so I'm not sure what the community rules are about this, but I want to ask something:

The linked manpage says the following about token-timeouts=:

Defaults to 30s.

neocats config wrote:

token-timeout=15

So the parameter was reduced. Wouldn't that be worse because the process doesn't wait as long? How does it fix it?

Last edited by archlynovice (2025-01-22 19:08:33)

Offline

#8 2025-01-22 20:06:46

libertepourmoi
Member
Registered: 2022-03-26
Posts: 16

Re: [SOLVED] Can't use different keyslot for LUKS decryption in initramfs

In the OP's configuration there is a password prompt once this timeout has expired. And if you plan to sometimes use the token, and sometimes the password, then I guess a long timeout is not in your interest because you have to wait for it to expire. When you want to use the token you simply plug it in before you switch on the computer, so you don't really need a timeout at all. That's how to me, the OPs decision makes sense.

Offline

Board footer

Powered by FluxBB