Second factor is ignored about mkinitcpio-ykfde

[eworm-de]

Ok, first of all... What version are you using?

Wondering if this is a timing issue. Please boot without Yubikey, enter the second factor, then insert the Yubikey. Any change?

[guiniol]

I'm using version 0.6.3.
I just realised there is a systemd-v230 version, so I'll try that in addition to the timing and report my findings.

[eworm-de]

The systemd-v230 tag is to mark the first commit that uses features in that systemd version.
Feel free to test git HEAD...

Looks like it is time for a release. But let's fix your issue first.

[guiniol]

Ok. I'll try tomorrow morning because I don't have the computer with me at the moment.

[guiniol]

So, if I plug in the yubikey after the prompt is displayed, then everything works as expected. Otherwise, I feel like it's not even trying, it immediately asks for the disk password. This is both with version 0.6.3 and HEAD.

[eworm-de]

Can you please try 0.6.3-14-g16cc1d8? Should work a lot more reliable.

[guiniol]

I tried, and I got the same behaviour. It works only if I plug the key after the prompt is displayed.

By the way, after I install, I only need to rebuild the initcpio, I don't need to use ykfde and ykfde-cpio, right? (For this test, I redid everything just to be sure).

[eworm-de]

I tried, and I got the same behaviour. It works only if I plug the key after the prompt is displayed.

Damn.

By the way, after I install, I only need to rebuild the initcpio, I don't need to use ykfde and ykfde-cpio, right? (For this test, I redid everything just to be sure).

Yes, right.

Ok, let's try to collect some information.

Let's build ykfde (the udev one) manually with simple debugging... Clone the git repository, go to the subdirectory udev and run:

gcc -std=c11 -O2 -fPIC -Wall -Werror -liniparser -lkeyutils -lykpers-1 -lyubikey -Wl,-z,now -Wl,-z,relro -pie -o ykfde ykfde.c -DDEBUG=1

Then copy ykfde to /usr/lib/udev/ykfde, rebuild your initramfs and try again. Error messages should appear on your display.

Also you could give the second factor, then let the prompt for LUKS passphrase time out. Start the shell and look around. Anything suspicious? Is the challenge in /etc/ykfde.d/ still available?

When you start the system (with and without debugging)... Any log entries in journal? Look for udev and ykfde.

[eworm-de]

Pushed some more changes, but that is just for proper clean up and should not have any impact on what you see.

If things keep failing... Can you please increase the sleep value in /usr/lib/systemd/system/ykfde-notify.service, rebuild your initramfs and try again?
And if that helps... What hardware (CPU) do use?

[guiniol]

So. Weird one.
If I clone the repo and build like you told me to, it works, both with and without debug mode.
If I install using the PKGBUILD in aur, which is supposed to clone and use the latest git HEAD, it doesn't. Maybe there's something in the gcc command line you gave me that isn't in the Makefile?

When I started the shell after letting LUKS timeout (with the version that worked), the challenge in /etc/ykfde.d/ had disappeared. I didn't try with the non-working version. When it works and I enter the wrong password, it actually tries to decrypt the disk before giving the LUKS prompt.

In the logs, I couldn't see much. My latest boot, with the non working version has a
systemd-udevd[139]: Process '/usr/lib/udev/ykfde' failed with exit code 1.
The boot where it worked has:

Jul 06 17:35:19 localhost systemd[1]: Starting Notify ykfde about key...
Jul 06 17:35:19 localhost systemd[1]: Started Notify ykfde about key.
Jul 06 17:35:26 localhost systemd[1]: Stopped Notify ykfde about key.

As for the hardware, I have a i7-4770HQ, with 16G of RAM in an crappy shell by schenker (no idea what the mobo could be).

[eworm-de]

If I clone the repo and build like you told me to, it works, both with and without debug mode.
If I install using the PKGBUILD in aur, which is supposed to clone and use the latest git HEAD, it doesn't. Maybe there's something in the gcc command line you gave me that isn't in the Makefile?

Wired... Just to make sure: What is the git hash of your last package?
For some time the package used to systemd-v230 tag to generate the version. Make sure you do not have version 230.x installed and pacman refuses to downgrade. :-D

The only difference in gcc command is that it defines DEBUG.

When I started the shell after letting LUKS timeout (with the version that worked), the challenge in /etc/ykfde.d/ had disappeared.

That's expected. The challenge is removed when challenge/response was successful.

I didn't try with the non-working version. When it works and I enter the wrong password, it actually tries to decrypt the disk before giving the LUKS prompt.

ykfde does not know whether or not the second factor is correct. It does challenge response and caches the response for LUKS.

In the logs, I couldn't see much. My latest boot, with the non working version has a
systemd-udevd[139]: Process '/usr/lib/udev/ykfde' failed with exit code 1.

That looks like an old version before the fix.

So to make sure please double check your installed version. Feel free to install one of my packages for testing:

http://mirror.mylinuxtime.de/arch/eworm/x86_64/mkinitcpio-ykfde-0.6.3.r16.ge2763d3-1-x86_64.pkg.tar.xz
http://mirror.mylinuxtime.de/arch/eworm/x86_64/mkinitcpio-ykfde-git-0.6.3.r16.ge2763d3-1-x86_64.pkg.tar.xz

(It's the same package, just different package name.)
The packages are signed, so you should be able to install with pacman -U directly from server.

[eworm-de]

As for the hardware, I have a i7-4770HQ, with 16G of RAM in an crappy shell by schenker (no idea what the mobo could be).

Just wanted to make sure you do not run on aged and under-powered Celeron. ;) That one should be fine and I think it does not suffer any timing issue. :-p

[guiniol]

That's expected. The challenge is removed when challenge/response was successful.

That's what I figured.

ykfde does not know whether or not the second factor is correct. It does challenge response and caches the response for LUKS.

So in the case where it doesn't work and it drops me directly to the LUKS prompt, then it's actually not trying to do anything.

Just wanted to make sure you do not run on aged and under-powered Celeron. ;) That one should be fine and I think it does not suffer any timing issue. :-p

ok ^^

So to make sure please double check your installed version. Feel free to install one of my packages for testing:

I'll check again, although I'm pretty sure pacman removed the package I had installed before because I used the non git version first and then the git version and I ended up with a .pacsave file. But anyhow, I'll check again.

[guiniol]

This morning, it works. I tried reinstalling from the AUR, and it warned me that I was reinstalling the same version (which is indeed 0.6.3.r16.ge2763d3-1) and now it works.
Not sure what to say now...

[eworm-de]

Wired...
However, if it works reliable now... Can we close the issue?

[guiniol]

Sure. I'll reopen it if needed.
Thanks a lot.

[guiniol]

This may be a hardware issue. This morning it doesn't work. I have done no updates from the previous comment, I only went on holidays. I tried upgrading to 0.6.4, but it still doesn't work. meh