Comment by jlgaddis | Hacker News Reader

Comment by jlgaddis | Hacker News Reader

Related (but slightly OT) question: has anyone ran into any issues when using either 1) a single Yubikey for both U2F and SSH authentication or 2) multiple Yubikeys simultaneously on the same machine (i.e., one for U2F, one for SSH)?

For SSH authentication, I use Yubikeys (and only Yubikeys) everywhere: my workstation at home (I WFH 99% of the time), my primary laptop, and a "backup" laptop. Each of these machines has its own "dedicated" Yubikey that I use to authenticate to remote SSH servers (a "Nano" that is left plugged in 24/7). I also use these (with challenge/response) to unlock encrypted LUKS volumes (containing ZFS pools) at boot, FWIW.

I would like to begin using U2F (AFAICT, U2F support should be coming to Firefox soon, if it hasn't already; running FF57 Developer Edition here), preferably with these same Yubikeys I am already using for SSH. If there are any issues, however, I'm fine with using a separate Yubikey just for the U2F side of things (I have a few U2F-only Yubikeys laying around as well).

Basically, I want it to be as easy/convenient as possible and, before I begin to attempt this, I'm just curious if anyone else is already doing this and, if so, what their experiences were and any issues they may have encountered. In theory, it should all just work but, in reality, well, who knows. TIA!

U2F should work with your Yubikeys, irrespective of your slot 1/2 configurations. U2F does not depend on slot provisioning. Unlike your slot/gpg keys, U2F authenticators are unique to each individual hardware component and cannot be replicated between Yubikeys.

I thought as much. I'm mostly curious about any possible "inter-op" issues with GnuPG and U2F functionality (for example, I have heard reports that gpg-agent would "reset" after a U2F auth and so would require a PIN on next use regardless of any timeouts; that's not a problem for me, just something I'd like to be aware of beforehand). Thanks!

Be prepared to pull and replace the Yubikey when switching between applets. I currently use a key configured with U2F, gpg (and ssh via gpg-agent), and oath totp. Usually it switches between applets seamlessly, requiring pin entry for gpg any time I switch back to gpg.

Occasionally whichever applet I'm attempting to use will appear unavailable, requiring the token be pulled and reseated.

Yeah, I've heard similar reports before and that's exactly the kind of thing I was wanting to hear about because, e.g., the Nano can be a PITA to remove sometimes -- especially on my workstation, where it is plugged into one of the USB ports on the "back" of a Das Keyboard. I don't mind punching in my PIN all the time (I already use short timeouts anyways), but removing and reinserting the Nano several times a day is inconvenient and will get annoying real quick.

Thanks.

I used to run into this regularly as well, usually with gpg-agent refusing to work. I recently switched to a 4C Nano, which made it quite cumbersome to pull the key, so I looked into it and found out that reloading gpg-agent does the trick as well. I use this alias to do that quickly:

    alias gpgpls='gpg-connect-agent reloadagent /bye'

I haven't needed to pull the key since. I'm on macOS and use gpg-agent, U2F and yubioath-desktop.

Oh, excellent, that's great to know. I run Arch Linux on these particular machines but, in this case, it probably doesn't matter. Thank you.

I'm replying to myself here but to anyone else interested, you can now -- unofficially, as of v57 -- use a U2F-enabled YubiKey in Firefox.

See the details on Mozilla's Wiki [0] (short version: in "about:config", enable "security.webauth.{u2f,webauthn}") and visit Yubico's online demo [1] to test it out.

[0]: https://wiki.mozilla.org/Security/CryptoEngineering#Using_U2...

[1]: https://demo.yubico.com/u2f

If people are going to leave the USB device in all the time, why not just use the onboard TPM the machine probably already has? At least on Windows, the TPM can create a virtual smart card so existing infrastructure can just use that as normal.

Then you get keys protected by hardware. Though the TPMs might commonly be easier to physically hack than good USB devices.

For U2F, there are two issues. First, communication doesn't use a smart card protocol, it uses a custom protocol over USB/HID. So to implement U2F using the TPM you would need to write a virtual USB device driver, which is a pain. Github wrote one for Mac, but there's nothing for Linux or Windows to my knowledge. Second, U2F calls for a physical presence check. With most existing hardware, there's no way for the TPM to verify physical presence, so it has to be done in the client software, which reduces the point somewhat. Newer hardware may address the second point, as I've seen some new laptops with TPMs hooked up to the fingerprint reader.

For other smartcard-y things: a lot of stuff gets called a "smart card", but any given application is going to involve a particular applet on a smartcard, and a particular client side implementation to use it. The Windows virtual smart card implements a PIV applet, I believe, whereas most of the Yubico stuff works using either non-standard applets or a PGP smartcard applet. So the client side would not be compatible with the Windows virtual smartcard.

Reply on news.ycombinator.com