Yubikey + LUKS on Qubes 4.1

Qubes 4.1 prompts for the yubikey password multiple times.

  1. In work: Setup the yubikey. (yubikey-personalization-gui).
  2. In work: Generate a yubikey passcode (ykchalresp -2 mypassword)
  3. In dom0: Add the passcode to luks. (sudo cryptsetup luksAddKey /dev/nvme0n1p3)
  4. Make grub support the yubikey (this is the hard part, so I scripted it)
#!/bin/bash
grub="/etc/default/grub"
echo "Converting $grub to use yubikey"
cp "$grub" "$grub.bak"
cat "$grub.bak" |
  sed -e 's@rd.luks.uuid=@rd.ykluks.uuid=@g' \
      -e 's@rd.qubes.hide_all_usb@rd.ykluks.hide_all_usb@g' > "$grub"

echo "Generating new bootloader"
grub2-mkconfig -o /boot/efi/EFI/qubes/grub.cfg
echo "Generating new kernel"
dracut -f

After rebooting, it prompts for the yubikey (good!).
I plug in the yubikey and enter my ykpassword. The little progresss bar at the bottom moves a little. Then it waits for me to enter my ykpassword a second time.
I enter my ykpassword again. The little progresss bar at the bottom moves a little more. Then it waits for me to enter my ykpassword a third time.
I enter my ykpassword again. Then it boots up.

Any idea why it’s asking for the ykpassword multiple times?

Well there is at least your root and most certainly your swap enncrypted maybe even more. and while luks seem to reuse prior entered passwords (dont know if this the case but feels like it) to decrypt all partitios when entered correctly. its mabe not possible in the same way with the yubikey.

With Qubes 4.0.3, it did not prompt for the password 3 times; it only prompted once. This is new to Qubes 4.1.

Why exactly are you disabling rd.luks.uuid= option(s) (by changing them into rd.ykluks.uuid=)? This actually may be the cause of your issue.

You can also review boot log (journalctl -b) and search for “Starting Cryptography Setup” entries - maybe it tries to unlock other partitions too (if you have some?), or it fails to unlock it initially and you can find more details why?

I was following the instructions at GitHub - the2nd/ykluks: Dracut module to use yubikey in challenge/response mode to unlock LUKS partition.
It worked for Qubes 4.0.3 and 4.0.4, so I assumed it would work for 4.1.

In the morning, I’ll put rd.luks.uuid= back and see what it does.

Ah, I see. That rd.ykluks.uuid may be needed in such case. But inspecting the log should still give more hints what is going on.

journalctl -b is interesting…

systemd-cryptsetup starts, sets the cipher, mode, etc. Then reports:

Jul 29 10:22:56 dom0 kernel: usb 1-5.1.2: Product: YubiKey OTP+FIDO+CCID
Jul 29 10:22:56 dom0 kernel: usb 1-5.1.2: Manufacturer: Yubico
Jul 29 10:22:56 dom0 kernel: input: Yubico YubiKey OTP+FIDO+CCID as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.2/1-5.1.2:1.0/0003:1050:0407.0003/input/input14
Jul 29 10:22:56 dom0 kernel: hid-generic 0003:1050:0407.0003: input,hidraw1: USB HID v1.10 Keyboard [Yubico YubiKey OTP+FIDO+CCID] on usb-0000:00:14.0-5.1.2/input0
Jul 29 10:22:56 dom0 kernel: hid-generic 0003:1050:0407.0004: hiddev96,hidraw2: USB HID v1.10 Device [Yubico YubiKey OTP+FIDO+CCID] on usb-0000:00:14.0-5.1.2/input1
Jul 29 10:22:56 dom0 kernel: usb 1-5.1.3: new full-speed USB device number 8 using xhci_hcd
Jul 29 10:22:56 dom0 kernel: usb 1-5.1.3: New USB device found, idVendor=04e6, idProduct=5116, bcdDevice= 2.04
Jul 29 10:22:56 dom0 kernel: usb 1-5.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 29 10:22:56 dom0 kernel: usb 1-5.1.3: Product: SCR3310 v2.0 USB SC Reader
Jul 29 10:22:56 dom0 kernel: usb 1-5.1.3: Manufacturer: SCM Microsystems Inc.
Jul 29 10:22:56 dom0 kernel: input: Yubico YubiKey OTP+FIDO+CCID as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.2/1-5.1.2:1.0/0003:1050:0407.0005/input/input15
Jul 29 10:22:56 dom0 kernel: hid-generic 0003:1050:0407.0005: input,hidraw1: USB HID v1.10 Keyboard [Yubico YubiKey OTP+FIDO+CCID] on usb-0000:00:14.0-5.1.2/input0
Jul 29 10:23:09 dom0 systemd-cryptsetup[453]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/1fe9df1b-1ef5-49e8-8012-00d0c2629ecf.
Jul 29 10:23:13 dom0 systemd-cryptsetup[453]: Failed to activate with specified passphrase. (Passphrase incorrect?)
Jul 29 10:23:21 dom0 systemd-tty-ask-password-agent[454]: Invalid password file /run/systemd/ask-password/ask.0kuQ2t
Jul 29 10:23:21 dom0 systemd-tty-ask-password-agent[454]: Failed to process password: Bad message
Jul 29 10:23:21 dom0 kernel: input: Yubico YubiKey OTP+FIDO+CCID as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.2/1-5.1.2:1.0/0003:1050:0407.0006/input/input16
Jul 29 10:23:21 dom0 kernel: hid-generic 0003:1050:0407.0006: input,hidraw1: USB HID v1.10 Keyboard [Yubico YubiKey OTP+FIDO+CCID] on usb-0000:00:14.0-5.1.2/input0
Jul 29 10:23:24 dom0 systemd[1]: Reloading.
...
Jul 29 10:23:27 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=dracut-initqueue comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 29 10:23:27 dom0 systemd[1]: Reached target Remote File Systems (Pre).
Jul 29 10:23:27 dom0 systemd[1]: Reached target Remote File Systems.
Jul 29 10:23:30 dom0 systemd-tty-ask-password-agent[454]: Invalid password file /run/systemd/ask-password/ask.rzEmMo
Jul 29 10:23:30 dom0 systemd-tty-ask-password-agent[454]: Failed to process password: Bad message
Jul 29 10:23:30 dom0 systemd-cryptsetup[453]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/1fe9df1b-1ef5-49e8-8012-00d0c2629ecf.
Jul 29 10:23:30 dom0 systemd-cryptsetup[453]: Device luks-1fe9df1b-1ef5-49e8-8012-00d0c2629ecf already exists.
Jul 29 10:23:30 dom0 systemd-cryptsetup[453]: Failed to activate with specified passphrase: File exists
Jul 29 10:23:30 dom0 systemd[1]: systemd-cryptsetup@luks\x2d1fe9df1b\x2d1ef5\x2d49e8\x2d8012\x2d00d0c2629ecf.service: Main process exited, code=exited, status=1/FAILURE
Jul 29 10:23:30 dom0 systemd[1]: systemd-cryptsetup@luks\x2d1fe9df1b\x2d1ef5\x2d49e8\x2d8012\x2d00d0c2629ecf.service: Failed with result 'exit-code'.
Jul 29 10:23:30 dom0 systemd[1]: Failed to start Cryptography Setup for luks-1fe9df1b-1ef5-49e8-8012-00d0c2629ecf.
Jul 29 10:23:30 dom0 systemd[1]: Dependency failed for Local Encrypted Volumes.
Jul 29 10:23:30 dom0 systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'.
Jul 29 10:23:30 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-cryptsetup@luks\x2d1fe9df1b\x2d1ef5\x2d49e8\x2d8012\x2d00d0c2629ecf comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Jul 29 10:23:30 dom0 systemd[1]: systemd-cryptsetup@luks\x2d1fe9df1b\x2d1ef5\x2d49e8\x2d8012\x2d00d0c2629ecf.service: Consumed 9.547s CPU time.
Jul 29 10:23:30 dom0 systemd[1]: Reached target System Initialization.
Jul 29 10:23:30 dom0 systemd[1]: Reached target Basic System.

(I’m sure that I typed the password correctly. It’s a test system so the password is “123”.)
I’m suspecting that it starts with an invalid /run/systemd/ask-password/ask.0kuQ2t file, then it recreates it and it works. (Race condition?)

Tried with rd.luks.uuid instead of rd.ykluks.uuid.
Nope – rd.ykluks.uuid is critical. Without it, the boot screen (black page with “Q” and text box) does not prompt for the yubikey. And if the yubikey is plugged in, it isn’t accessed to validate the passphrase. (The yubikey’s light doesn’t blink.)

@marmarek I think I found the cause of the 3 password prompts (black “Q” luks page with Yubikey).

The first password is always wrong. Doesn’t matter if you type it correctly, it’s always wrong. Maybe a bad character buffer? Acts like an uninitialized buffer, or something initialized with junk. (Failing the password clears the buffer, and gives the second password prompt.)

The second password is the real password. It checks and gives a message about receiving a response from the yubikey and the luks drive being unlocked.

The third password prompt is a bug. It doesn’t matter what you enter, it is ignored. (I intentionally entered a bad password, it didn’t care.) But you must enter something to get past the prompt. Then the OS boots.

Update: Reconfirmed

  1. The first prompt says “Disk password”. Just press enter. This password is ignored.
  2. The prompt changes to “Password”. Enter the yubikey passphrase. (Received response from Yubikey. Luks device opened.)
  3. The third prompt says “Disk password”. Type anything; it is ignored. Then the system boots.
1 Like

Possibly related: if you enter the wrong yubikey passcode at the “Password” prompt, then no number of re-entering the passcode will permit you to login. It looks like it wrote a temp file and is failing to overwrite it with the re-entered passcode.

The solution is to hard-reboot and do it again.

Update: Grrr… this is inconsistent. Sometimes a second password works, but sometimes a bad password cannot be recovered. (File locking issue? Permissions? Uninitialized buffer? Where’s the source code for this?)

Maybe this deserves a formal bug report?

Good idea! Done: 2FA with Yubikey prompts for unused passwords. · Issue #6823 · QubesOS/qubes-issues · GitHub

1 Like