systemd version the issue has been seen with

251.5

Used distribution

NixOS

Linux kernel version used

6.0.3

CPU architectures issue was seen on

x86_64

Component

systemd-cryptsetup

Expected behaviour you didn't see

I wanted to configure a systemd-cryptsetup config where I would have 2 slots enrolled both of which are FIDO2 keys (I've got 1 daily-use YubiKey and then another one as a backup in a safe). When I started using systemd-cryptenroll I added my first FIDO2 key to the second slot (password being the 1st slot). I then decided to delete the 1st slot which has the old traditional password as I no longer needed it can am able to unlock the LUK2 device with just the FIDO2 key. I deleted the password and then wanted to add my second (backup) FIDO2 key via systemd-cryptenroll but it seems that systemd-cryptenroll always asks for a normal passphrase which I no longer have, so I cannot enroll another slot. Luckily I am not locked out as I can unlock the device with just the FIDO2 key but I can't enroll new slots with it. It would be great If having a password wouldn't be a requirement to enroll new slots via systemd-cryptsetup that way I can add more non password/recovery slots without having the need to have one enrolled. Ideally I would have a setup where I have two FIDO2 keys enrolled without any traditional password.

Unexpected behaviour you saw

systemd-cryptenroll did not prompt me to use my only slot (the FIDO2 one) to enroll a second slot. It only prompted me to unlock with a password which I already deleted.

Steps to reproduce the problem

1. Run systemd-cryptenroll on a device and notice that there is already a password slot enrolled
2. Enrolled one of the FIDO2 keys I have
3. Test that unlocking/mount the device via the newly enrolled FIDO2 keys works
4. Delete the password slot from before as it's no longer needed
5. Try to enroll another slot- it prompts for a password that no longer exists and doesn't try to authenticate via the only existing slot available which isn't a password one

Additional program output to the terminal or log subsystem illustrating the issue

No response