Could not config yubikey on Tails

[dolanjs]

I was not able to get the yubikey-personalization-gui package to configure a yubikey on Tails. It kept saying firmware is not supported. This was a new replacement yubikey not the one with the vuln from a month or to ago.

To reproduce:

1. Boot tails
2. sudo apt-get update
3. sudo apt-get install yubikey-personalization-gui
   4a) yubikey-personalization-gui
   4b) also tried running the configuration with sudo but same result
4. Insert yubikey

And it will say in the top left corner of the gui that the Firmware is not supported. Also tried it on different my hardware/tails and the someone else's different hardware/tails.

I had to boot to their regular OS and configure the yubikey there. Once the yubikey is configured it works fine on tails just was not able to do the initial configuration of it in tails

[garrettr]

We encountered this issue again in a recent installation, using Tails 1.5.1. While the yubikey-personalization-gui did not say "firmware is not supported", it failed to show the Yubikey as "connected" even after it was plugged in. I am not sure if this is the same or a separate issue as what was originally reported here.

The bug we encountered recently was a dupe of this bug on the Ubuntu issue tracker. The admin was using a Yubikey Edge, and from the Ubuntu bug:

The software you need a newer version of is libykpers-1-1 (from yubikey-personalization) and you need at least version 1.16.2 where the Edge is supported.

Tails is currently based on wheezy (oldstable), so the version of libykpers-1-1 in their repos is 1.7.0-1. However, Tails also includes the Debian testing repos in the apt sources list by default, so we were able to install the required version of libykpers-1-1 (and the corresponding updated version of yubikey-personalization-gui) with the following command:

sudo apt-get install yubikey-personalization-gui=3.1.21-1 libykpers-1-1=1.17.1-1

With this updated software, we were able to successfully configure the Yubikey on Tails.

Note that the package versions in the testing/unstable repos are prone to change, so this apt-get install command is not future-proof. We also don't know how if it might cause problems with other software on Tails (because it also installs a bunch of other dependencies from the testing repo, e.g. for required graphics libraries), although we didn't see anything like that during the recent install. We also don't know how this will persist across reboots in Tails.

Another potential idea would be to use the Yubico PPA although I'm not sure if that will work on Debian/Tails, and if we'd be able to get the PPA to persist across reboots.

[tildelowengrimm]

The Yubico PPA generally works on Debian, though both the unstable packages and the PPA ones are rapid-release and shift like the sand and the tides. I don't think it's likely that a 1.16.2+ version is going to be stabilized too soon, though it may be worth reaching out to contacts at Yubico to see if they can help us out — it's possible that SecureDrop isn't the only place that this fiddliness is an issue.

I think that the best-case shortish fix is to give a ≥ install command in the setup docs/scripts, rely on apt only to upgrade, and hope that there are no new bugs. A convenient middle ground might be getting an official backport of those packages?

[tildelowengrimm]

It's necessary to run the GUI as root, but the GUI doesn't do that by default. This feels like an upstream bug, though the fix is probably not in running the GUI as root but in changing some underlying permissions issue. Fixing this in a (backported?) package would be great because it'd remove any re-twiddling responsibilities from individual admins.

It is not necessary to set up UDEV rules unless using U2F. Related: U2F is so much better than HOTP and that should be the default 2FA option. That's a separate issue, though.

[psivesely]

Just tried this w/ Tails 1.7. I could not use any version of yubikey-personalization-tool besides the one in oldstable because of unresolvable dependencies. Did not try the PPA. The version in oldstable, currently 3.0.6, did not recognize when I inserted either a most recent generation YK Neo or the RC1 of the next generation. It did not say the firmware was unsupported; it was not recognized at all.

[tildelowengrimm]

You need to install yubikey-personalization-gui and libykpers-1-1 v1.16.2 and then run yubikey-personalization-gui as root.

[psivesely]

So as it is, you can only install oldstable/yubikey-personalization-gui (3.0.6-1) for dependency reasons. You can, however, install libykpers-1-1 from oldstable (1.7.0-1), stable (1.16.0-1), and testing (1.17.2-1). 1.17.2-1 is also the version in unstable.

Like I said earlier, I have two a YK Neos: one is a YK3 (firmware version 3.4.3) and the other a YK4-rc1 (4.2.5).

Neither worked with libykpers-1-1 from oldstable, the YK3 worked with stable, and both worked w/ testing.

[psivesely]

So the best option for now seems to be to change the docs to:

# apt-get update
# apt-get install yubikey-personalization-gui
# apt-get install -t testing libykpers-1-1
# yubikey-personalization-gui

[tildelowengrimm]

It looks like the dependency issue is new — thanks to the roiling chaos that is Debian Testing. That makes me think that any action taken in reliance on the it is likely to be at best temporary. One option would be to do what effectively amounts to a dist-upgrade to Testing in order to provision Yubikeys. Alternatively, perhaps admins should temporarily use another live system for this work?

[heartsucker]

Marking "Pending close" since this reference Tails 1.5.x and 1.7.x. If this issue persists in the 3.x series, I assume this conversation won't be helpful in debugging it.

[conorsch]

Good points, @heartsucker. However, I must admit that even during hardware testing, I rarely use a Yubikey for the 2FA—I always go with the TOTP option. Let me run through a new account creation with HOTP in Tails 3.1 and confirm no problems, then I'm fine with closing this.

[conorsch]

Confirmed the HOTP config is valid. The Yubikey docs are not inaccurate, but are markedly less clear than the rest of the documentation base. I'll open a separate issue to clean up the Yubikey docs. Thanks for flagging this issue, @heartsucker—closing now.