I have already posted a howto on how to set up the YubiKey NEO and YubiKey NEO-n for U2F, and I promised I would write a bit more on the adventure to get the software packaged in Gentoo.
You have to realize at first that my relationship with Yubico has not always being straightforward. I have at least once decided against working on the Yubico set of libraries in Gentoo because I could not get a hold of a device as I wanted to use it. But luckily now I was able to place an order with them (for some two thousands euro) and I have my devices.
But Yubico’s code is usually quite well written, and designed to be packaged much more easily than most other device-specific middleware, so I cannot complain too much. Indeed, they split and release separately different libraries with different goals, so that you don’t need to wait for enough magnitude to be pulled for them to make a new release. They also actively maintain their code in GitHub, and then push proper
make dist releases on their website. They are in many ways a packager’s dream company.
But let’s get back to the devices themselves. The NEO and NEO-n come with three different interfaces: OTP (old-style YubiKey, just much longer keys), CCID (Smartcard interface) and U2F. By default the devices are configured as OTP only, which I find a bit strange to be honest. It is also the case that at the moment you cannot enable both U2F and OTP modes, I assume because there is a conflict on how the “touch” interaction behaves, indeed there is a touch-based interaction on the CCID mode that gets entirely disabled once enabling either of U2F or OTP, but the two can’t share.
What is not obvious from the website is that to enable U2F (or CCID) modes, you need to use yubikey-neo-manager, an open-source app that can reconfigure the basics of the Yubico device. So I had to package the app for Gentoo of course, together with its dependencies, which turned out to be two libraries (okay actually three, but the third one
sys-auth/ykpers was already packaged in Gentoo — and actually originally committed by me with Brant proxy-maintaining it, the world is small, sometimes). It was not too bad but there were a few things that might be worth noting down.
First of all, I had to deal with
dev-libs/hidapi that allows programmatic access to raw HID USB devices: the ebuild failed for me, both because it was not depending on udev, and because it was unable to find the libusb headers — turned out to be caused by bashisms in the
configure.ac file, which became obvious as I moved to
dash. I have now fixed the ebuild and sent a pull request upstream.
This was the only real hard part at first, since the rest of the ebuilds, for
app-crypt/yubikey-neo-manager were mostly straightforward — only I had to figure out how to install a Python package as I never did so before. It’s actually fun how distutils will error out with a violation of install paths if
easy_install tries to bring in a non-installed package such as
nose, way before the Portage sandbox triggers.
The problems started when trying to use the programs, doubly so because I don’t keep a copy of the Gentoo tree on the laptop, so I wrote the ebuilds on the headless server and then tried to run them on the actual hardware. First of all, you need to have access to the devices to be able to set them up; the
libu2f-host package will install udev rules to allow the
plugdev group access to the
hidraw devices — but it also needed a pull request to fix them. I also added an alternative version of the rules for systemd users that does not rely on the group but rather uses the ACL support (I was surprised, I essentially suggested the same approach to replace
pam_console years ago!)
Unfortunately that only works once the device is already set in U2F mode, which does not work when you’re setting up the NEO for the first time, so I originally set it up using
kdesu. I have since decided that the better way is to use the udev rules I posted in my howto post.
After this, I switched off OTP, and enabled U2F and CCID interfaces on the device — and I couldn’t make it stick, the manager would keep telling me that the CCID interface was disabled, even though the USB descriptor properly called it “Yubikey NEO U2F+CCID”. It took me a while to figure out that the problem was in the
app-crypt/ccid driver, and indeed the change log for the latest version points out support for specifically the U2F+CCID device.
I have updated the ebuilds afterwards, not only to depend on the right version of the CCID driver – the README for
libykneomgr does tell you to install pcsc-lite but not about the CCID driver you need – but also to check for the HIDRAW kernel driver, as otherwise you won’t be able to either configure or use the U2F device for non-Google domains.
Now there is one more part of the story that needs to be told, but in a different post: getting GnuPG to work with the OpenPGP applet on the NEO-n. It was not as straightforward as it could have been and it did lead to disappointment. I’ll be a good post for next week.
On OpenPGP and OpenSSH, is there anything you need to add to:https://blog.habets.se/2013…?
Kinda, I actually have some instructions myself at https://blog.flameeyes.eu/2… that matches mostly what you have, but avoids using a ssh wrapper.My problem is mostly to add about using GnuPG and multiple CCID devices. It’s going to be a pain for me, but probably won’t add much to people.
Two thousands euro? WTH, did you just buy the tray of 50 NEO’s? For everyone in your large family? Crazy.
No we did a joint order at the office, you’d be surprised how easy it is to burn through credit that way. I had to stop at 2k because otherwise I wouldn’t have had a credit card capable of accepting the order.
[quote]Now there is one more part of the story that needs to be told, but in a different post: getting GnuPG to work with the OpenPGP applet on the NEO-n. It was not as straightforward as it could have been and it did lead to disappointment. I’ll be a good post for next week.[/quiote]When can we really expect the post?
Realistically, as soon as I have a moment to test GnuPG 2.1.0 since it seems to have a bunch of fixes for smartcard support.I wouldn’t want o write a long rant about GnuPG just to be pointed at the bugfixes already being there in the new release…
I noticed that only the ~amd64 keyword is set on the various Yubikey packages.I’m trying to install the software on a x86 machine. Do you foresee serious problems? Is this stuff (app-crypt/yubikey-neo-manager and friends) known to be broken on x86?
The only reason why it’s not marked ~x86 is that neither me nor others who use these packages seem to run a 32-bit system. If you can test it and vouch for it working, just open a bug so that it is marked as such.