Works with RHEL8?

[superteece]

This is more of a "How Do?" than an issue, my apologies. I've followed the guide and installed this onto a RHEL 8 machine. I can still unlock the disk and boot with my original LUKS password but I guess I'm not fully understanding this project's operation. For context I'm a user of the Arch and Debian Yubikey-LUKS projects and maintain a fork of the Debian version with some additions for my use case.

In this project, if ykfde is ran with no args, what happens? Is the Yubikey effectively a 1fa device in this method? I.E. is the challenge stored on disk somewhere and referenced during boot? If so, this is not happening for me.

I do get an error when running ykfde that Not running from systemd, you may have to give second factor manually if required. is this related?

My use case for Yubikey and LUKS is that it effectively be a 1fa device from a user's perspective. A user will connect the Yubikey to a headless machine and boot without having to interact. I can do this with Debian but I need to also have the ability with RHEL.

[superteece]

I was causing the error by not specifying --new-2nd-factor and defining what the 'known' factor would be. However, once setting correctly, the boot process isn't accepting that, it's apparently not seeing or using the YubiKey. In the Debian project, the LUKS prompt at boot gives status that it's accessing the YubiKey -- should I expect the same from this project? And is there a way to store the secret so that the boot process is automated without the user having to type in the 'known' factor. (I realize this largely negates "2fa" but it's my use case.

[eworm-de]

RHEL8 does use dracut for generation of initramfs, right? I've never used that myself. (I run Arch Linux with mkinitcpio, the dracut support was added by contributor.)

You can use second factor, but you do not need to. Make sure to modify /etc/ykfde.conf accordingly. That said... I am not sure you touched the configuration at all. Did you? Please give more detail what your actual configuration looks like.

If you do not use second factor running ykfde without arguments should update the challenge in /etc/ykfde.d/ and change the LUKS passphrase for configured slot. Ignore the warning if you do not have second factor, ykfde is not aware of that.

[superteece]

Yup RHEL 8 is using dracut.

I setup the config per the instructions: a section identified by the yk's serial, the crypt device mapper name, left 'use second factor' as yes. So I need to switch that to no? Then run ykdfe with no args, ykfde-cpio, then dracut -f?

[eworm-de]

... left 'use second factor' as yes. So I need to switch that to no?

That controls whether or not the boot process asks for the second factor. If the system is headless and second factor is not used you should switch that to no.

Sounds like the remaining thing are correct, yes.

[superteece]

Thank you for the clarifications. I'll report back once I give it a shot.

[superteece]

No joy, the machine still boots to the prompt asking me to enter a LUKS passphrase.

ykfde no longer produces the systemd error. No errors are displayed.

ykfde.conf:

device name = <name found in /etc/crypttab>

use 2nd factor = no

[ykserial] luks slot = 1

[superteece]

When I got to the last section concerning GRUB, my machine did not have an existing /boot/grub2/grub.conf though it did have the /etc/default/grub file, to which I added the required var.

I ran grub2-mkconfig as per the instructions.

Maybe there's something changed in the most recent RHEL 8.2 use of Systemd boot?

[eworm-de]

No joy, the machine still boots to the prompt asking me to enter a LUKS passphrase.

Just to make sure... The message presented is the default one from systemd-ask-password ("Please enter passphrase for disk ..."), no? Please check if the initramfs contains the required file. Just grepping the the list of files for ykfde should give some results.

ykfde no longer produces the systemd error. No errors are displayed.

You disabled second factor in configuration, right? This disables the check as it is not needed. ;) Running ykfde is successful if it return with code 0.

[eworm-de]

Well, does your system boot with grub at all? If it does... Depends on the version if the mentioned variable is supported I think. Best to check the final configuration for expected initcpio filename.

[superteece]

Correct, I get the standard Please enter passphrase...

I grepped everything in the /boot dir. Only one file came back containing ykfde

grep -i ykfde /boot/*
grep: /boot/efi: Is a directory
grep: /boot/grub2: Is a directory
grep: /boot/loader: Is a directory
Binary file /boot/ykfde-challenges.img matches

[superteece]

Wait, this is probably more better :)

lsinitrd /boot/initramfs-4.18.0-193.28.1.el8_2.x86_64.img |grep ykfde
ykfde
-rw-r--r--   1 root     root         1022 Feb 28  2020 etc/udev/rules.d/20-ykfde.rules
-rw-r--r--   1 root     root          823 Feb 28  2020 etc/ykfde.conf
lrwxrwxrwx   1 root     root           23 Feb 28  2020 usr/lib/systemd/system/sysinit.target.wants/ykfde-worker.service -> ../ykfde-worker.service
-rw-r--r--   1 root     root          405 Feb 28  2020 usr/lib/systemd/system/ykfde-worker.service
drwxr-xr-x   2 root     root            0 Feb 28  2020 usr/lib/ykfde
-rwxr-xr-x   1 root     root        21144 Feb 28  2020 usr/lib/ykfde/worker
-rwxr-xr-x   1 root     root           50 Feb 28  2020 usr/sbin/ykfde.sh

[eworm-de]

Yes, output of lsinitrd looks kind of expected. So please make sure your boot loader does actually load the extra initramfs.

[superteece]

So please make sure your boot loader does actually load the extra initramfs.

I do believe this is where my problem is, I'm researching how to do this in systemd-boot

Thank you for the guidance thus far :smiley:

[superteece]

GOT IT!!!

Adding initrd /ykfde-challenges.img above the existing initrd entry of the loader file in /boot/loader/entries/ did the trick!

I'll try to capture this as an addition to the instructions some time this weekend.

Thanks!

[eworm-de]

Great, so have fun! 😃 (And leave a star if you have not.)

[superteece]

Hey, as a quick follow up. Adding that line to the entry config does work. But, if the kernel is updated a new entry config is generated which will not have this custom initrd line. This means the next boot will not use the Yubikey to unlock. Any ideas on what controls the generation or default entries into the /boot/loader/entries/.conf file? I'm looking at the kernel-install utility - created a custom .install file in /etc/kernel/install.d but that didn't work.

[eworm-de]

Sorry, no idea... I do not have RHEL (or anything similar) around. But let me know if you figure - would like the update the manual.