Issues with Yubikey 4 input

180 views
Skip to first unread message

Jon R.

unread,
Mar 9, 2018, 12:34:06 PM3/9/18
to qubes...@googlegroups.com
Hello,

I've scoured around the mailing lists / SO / Reddit and haven't come across a solution to this yet. I'm running 4.0 (R4.0) and when I attempt to use my Yubikey it's seemingly not picking up any input on the button press.

It's detecting the USB properly and I can attach it fine:

[cloe@dom0 Desktop]$ qvm-usb
BACKEND:DEVID  DESCRIPTION                                     USED BY
sys-usb:2-1    Yubico_Yubikey_4_OTP+CCID

[cloe@dom0 Desktop]$ qvm-usb attach work sys-usb:2-1

[cloe@dom0 Desktop]$ qvm-usb
BACKEND:DEVID  DESCRIPTION                                     USED BY
sys-usb:2-1    Yubico_Yubikey_4_OTP+CCID                       work

However upon button presses on the Yubikey in the "work" domain there is no action. I've tested this in gedit, the terminal and elsewhere to no avail.

Can someone point me in the right direction as to what may be happening? I've successfully attached storage devices and other smart card related devices without any issue so it seems to be isolated to the Yubikey itself. I've tried 2 separate Yubikey 4's and an older version to no avail.

Thank you for your time.

- Cody

William Bormann

unread,
Mar 9, 2018, 4:13:45 PM3/9/18
to qubes-users
I have a FIDO U2F Yubico Security Key that I use for authentication to Gmail and Facebook. In my situation, I decided to use a single VM for two factor authentication. Here's what I did:

1. Find a free USB controller. I didn't want to use the same one as my keyboard or mouse. Your board specs and the lsusb utility are your friends in the hunt. Check out the Qubes document "Assigning Devices to VMs" for the gory details of discovering the PCI device assignments to your USB controllers.
2. In the VM you plan to use the key, you'll want to assign the PCI device for your free hub to that VM. That's accomplished by firing up Qube settings for the VM and selecting the devices tab. Scroll down to the available device and move it to the selected box.
3. You might have to configure strict reset (or disable strict reset) for the USB controller.
4. Start the VM.

One gotcha: the VM won't run in PVH mode once you make this assignment. But, my Yubikey lights up when Gmail or Facebook need the second factor, and it works as advertised.

Jon R.

unread,
Mar 9, 2018, 9:05:09 PM3/9/18
to qubes...@googlegroups.com
1.  Find a free USB controller.  I didn't want to use the same one as my keyboard or mouse.  Your board specs and the lsusb utility are your friends in the hunt.  Check out the Qubes document "Assigning Devices to VMs" for the gory details of discovering the PCI device assignments to your USB controllers.
2.  In the VM you plan to use the key, you'll want to assign the PCI device for your free hub to that VM.  That's accomplished by firing up Qube settings for the VM and selecting the devices tab.  Scroll down to the available device and move it to the selected box.
3.  You might have to configure strict reset (or disable strict reset) for the USB controller.
4.  Start the VM.

One gotcha:  the VM won't run in PVH mode once you make this assignment.  But, my Yubikey lights up when Gmail or Facebook need the second factor, and it works as advertised.


It looks like when in the sys-usb Qube the Yubikey works as intended. When attaching it to another Qube it's listed under lsusb properly and lights up accordingly however when using it there is no output (to stdout / wherever). I'm not quite sure how to debug this further so if someone could shed some light in that regard that'd be great.

In the interim I'll use a solution similar to yours and just juggle the USB controller to different Qubes as needed (ick!).

Thanks for the information!


--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7e00edc7-3c2a-462e-98c6-443dd1af7d36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Yuraeitha

unread,
Mar 9, 2018, 10:17:42 PM3/9/18
to qubes-users
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
>
> To post to this group, send email to qubes...@googlegroups.com.
>
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7e00edc7-3c2a-462e-98c6-443dd1af7d36%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

I believe it could possibly be a qvm-usb bug, there appears to be some of those lately which needs fixing, so it might just be a question of waiting. If you want to speed that up, then you can do a search on github to double-check for existing open/closed issues, if there are none already posted for this issue, then you can post it there. If they are closed, then request it to be re-opened if there are no other duplicate open. Remember to include search for other USB devices that fail when using qvm-usb, of which the yubi key might fall under. If you find one of those without yubi key information, then you can add your details in that existing issue.

ThierryIT

unread,
Mar 16, 2018, 3:50:00 AM3/16/18
to qubes-users
I had the same problem than yours ...
I was able, after a looong period of fight, to attached my Yubikey but it was not working ...
I have found that it was not working with Firefox but only with Chrome ... I am only using mu Yubikey to manage my PGP kys and to be authenticated on web site like Github ...

Thx

Jon R.

unread,
Mar 16, 2018, 4:23:51 PM3/16/18
to qubes...@googlegroups.com
> I have found that it was not working with Firefox but only with Chrome ... I am only using mu Yubikey to manage my PGP kys and to be authenticated on web site like Github ...

Thanks for the information. My issue seems to be related to the USB passthru / sys-usb. I haven't had time to debug it further but I can't even get the OTP / smart card functionality to be produced outside of the sys-usb Qube. Once I scour the mailing list / GitHub issues I'll update here if I find anything pertinent.

Cheers!

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscribe@googlegroups.com.

To post to this group, send email to qubes...@googlegroups.com.

Marek Marczykowski-Górecki

unread,
Mar 18, 2018, 11:43:42 AM3/18/18
to Jon R., qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Looks like the X server in target VM cannot access the device. See
~/.local/share/xorg/X.0.log there for lines like this:

[247082.612] (EE) xf86OpenSerial: Cannot open device /dev/input/event1
Permission denied.
[247082.612] (II) event1: opening input device '/dev/input/event1' failed (Permission denied).
[247082.612] (II) event1 - failed to create input device '/dev/input/event1'.

In Fedora there is "ykpers" package, which ships appropriate udev rules
to fix permissions.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqoECkACgkQ24/THMrX
1ywKfgf/VZgu5vIHC0sNztwJU6+8nZ23LaBtoEAceGdN3v9GZCkVY0kFDQ6jDhKO
Jzp3wVPNM2XopNXmo+5mCgheL6nFGEQZfv6yB4MSwAUqqzcKxXy3eBkxAvAHfr3F
g0H/lEYLLQImuoaEgz0RfQZUwxz3VKItakj2S6tqUfDzUvprFTo1Gvhv/xT1wp+6
OcfK953ID4pl1DTBdf18DOQcTFIxWplGpHBEScJVjFVrtVtxlW72c/kJvliEl7uh
EQjGtCM3MHNL4GC2x8+n5aWrfva9tiEqVXlubvo/ReFbCtpqISxJI8TQkCi1IC8g
pAbBb8scoDJ9ik97GjvhMfoDuXwZvw==
=Ut6d
-----END PGP SIGNATURE-----

Jon R.

unread,
Mar 19, 2018, 12:17:33 AM3/19/18
to qubes...@googlegroups.com
> Looks like the X server in target VM cannot access the device. See
> ~/.local/share/xorg/X.0.log there for lines like this:
>
>    [247082.612] (EE) xf86OpenSerial: Cannot open device /dev/input/event1
>            Permission denied.
>    [247082.612] (II) event1: opening input device '/dev/input/event1' failed (Permission denied).
>    [247082.612] (II) event1  - failed to create input device '/dev/input/event1'.

> In Fedora there is "ykpers" package, which ships appropriate udev rules
> to fix permissions.

This doesn't appear to be the issued. The only relevant messages I'm seeing in both the sys-usb VM & the one I'm attaching it to (personal in this case) is the following:

> [   684.323] (II) config/udev: Adding input device Yubico Yubikey 4 OTP+CCID (/dev/input/event8)
> [   684.323] (II) No input driver specified, ignoring this device.
> [   684.323] (II) This device may have been added with another device file.

This appears in the sys-usb ~/.local/xorg/Xorg.0.log upon plugging in the Yubikey however the Yubikey functions as usual. When attaching the device to another VM the local ~/.local/xorg/Xorg.0.log shows the same message as above however it does not work.

Just to remove the udev rules being the potential culprit I added both ykpers / ykpers-devel to the fedora template and rebooted. The same behavior persists.

Jon R.

unread,
Mar 21, 2018, 2:38:25 PM3/21/18
to qubes...@googlegroups.com
Just a brief update on this -- I snagged a few Yubikey FIDO specific devices and they seem to work fine and as you'd expect. The issue seems to be isolated to the Yubikey 4 / the ones that support smart card features / things of that nature.

Color me confused.

On Mon, Mar 19, 2018 at 12:17 AM, Jon R. <bil...@gmail.com> wrote:
> Looks like the X server in target VM cannot access the device. See
> ~/.local/share/xorg/X.0.log there for lines like this:
>
>    [247082.612] (EE) xf86OpenSerial: Cannot open device /dev/input/event1
>            Permission denied.
>    [247082.612] (II) event1: opening input device '/dev/input/event1' failed (Permission denied).
>    [247082.612] (II) event1  - failed to create input device '/dev/input/event1'.

> In Fedora there is "ykpers" package, which ships appropriate udev rules
> to fix permissions.

This doesn't appear to be the issued. The only relevant messages I'm seeing in both the sys-usb VM & the one I'm attaching it to (personal in this case) is the following:

> [   684.323] (II) config/udev: Adding input device Yubico Yubikey 4 OTP+CCID (/dev/input/event8)
> [   684.323] (II) No input driver specified, ignoring this device.
> [   684.323] (II) This device may have been added with another device file.

This appears in the sys-usb ~/.local/xorg/Xorg.0.log upon plugging in the Yubikey however the Yubikey functions as usual. When attaching the device to another VM the local ~/.local/xorg/Xorg.0.log shows the same message as above however it does not work.

Just to remove the udev rules being the potential culprit I added both ykpers / ykpers-devel to the fedora template and rebooted. The same behavior persists.

brenda...@gmail.com

unread,
Mar 22, 2018, 8:32:45 AM3/22/18
to qubes-users
On Wednesday, March 21, 2018 at 2:38:25 PM UTC-4, Jon R. wrote:
> Just a brief update on this -- I snagged a few Yubikey FIDO specific devices and they seem to work fine and as you'd expect. The issue seems to be isolated to the Yubikey 4 / the ones that support smart card features / things of that nature.
>
> Color me confused.

A U2F Yubikey has a single USB "interface" that provides the U2F functionality. Yubikey NEOs/4s out of the box are setup to provide three USB "interfaces": U2F, classic Yubikey (two slots, HID based) and CCID (smart card) "interfaces". Discussion of USB "interfaces" can be found here: https://stackoverflow.com/questions/33103711/whats-difference-between-configuration-and-interface-in-usb-device

As I read it, if the device works in sys-usb but doesn't work in other VMs using the same template, perhaps the qubes/xen code that handles reassigning USB devices doesn't handle multi-interface USB devices well?

Perhaps try temporarily configuring your Yubikey 4 to disable OTP and CCID (leaving only the U2F interface enabled) using the Yubikey NEO Manager and see if that allows the U2F to function when the USB device is assigned to a VM. IF that works, see if other combinations (U2F+CCID, U2F+OTP) work or don't.

Brendan

john

unread,
Apr 7, 2018, 3:45:08 PM4/7/18
to qubes...@googlegroups.com
By "Chrome" did you mean "chromium" or only "Chrome" , if so be curious
how you installed "Chrome", as I recall, Chrome was supposed to built
in U2F for gmail 2FAuth ; however FFox never has, and there is/was
probably a defunct "extension" for the U2F.

Personally, I am needing urgently to have HOTP / OTP to work for my
lastpass password manager.

The latest is I've installed new Yubikey packages in Fedora-26 and Dom0
and tried attaching the key and the other USB "biometric" thing via
the widget (in 4.0) both individually and together, to no avail.

I'm wondering if this might have something to do with Yubikey's design
of actually mimic'ing a keyboard

PS: This isn't just with the " Yubikey 4 "(I don't have that
key...& as another poster posted in this thread), I have 2 of the
earlier Yubi keys the Neo and another earlier one


brenda...@gmail.com

unread,
Apr 7, 2018, 9:04:01 PM4/7/18
to qubes-users
There’s one more thing I just learned; by default, usb keyboards are blocked from all VMs. You have to modify /etc/qubes-rpc/policy/qubes.InputKeyboard to allow the Yubikey to be connected to a specific VM if the classic yubico otp slots are enabled...because they mimic a keyboard.

Brendan

john

unread,
Apr 9, 2018, 4:56:47 PM4/9/18
to qubes...@googlegroups.com
On 04/07/2018 03:04 PM, brendan.hoar-
> There’s one more thing I just learned; by default, usb keyboards are blocked from all VMs. You have to modify /etc/qubes-rpc/policy/qubes.InputKeyboard to allow the Yubikey to be connected to a specific VM if the classic yubico otp slots are enabled...because they mimic a keyboard.

modify it how please ?


I actually have 2 yubikey versions the newer Neo, and an older OTP
version ; I'm wondering if I should also attempt to disable everything
*but OTP in the personalization tool, which I'm reticent to mess with

john

unread,
Apr 10, 2018, 8:07:43 PM4/10/18
to qubes...@googlegroups.com
Today, I made the yubikey into OTP only via the Neo personalisation tool
& set qubes.InputKeyboard RPC to
$anyvm $work allow

reboot the AppVM attached the yubikey to work AppVM, however it is
still dead in the water ...

I only need OTP (I have the dom0 and fedora packages installed) , so,
I see no further leads, though I Do recall Axon Andrew mentioning
something about SALT for HID keyboards ..... I really need the yubikey
to work sigh

john

unread,
Apr 10, 2018, 10:28:08 PM4/10/18
to qubes...@googlegroups.com
On 03/15/2018 09:50 PM, ThierryIT wrote:
--
ThierryIT
Feb 27
Translate message to English
- show quoted text -
Hi,

The problem was a mix of Fedora-26 template between my old R3.2 and the
R4.4.
When installed the right package version of "qubes-core-agent" who
should be: 4.0.23, I am able to attached the Yubikey. Nothing more has
to be done.
Thx anyway for your full support.
Thx
--


How do I check my qubes-core-agent and/or make sure it is 4.0.23
please ?
Reply all
Reply to author
Forward
0 new messages