1. 13
  1.  

  2. 7

    I did this for a while.. It mostly worked well but never worked great. The pcscd / gpg-agent dance was flaky.. and most days would have to start one or the other.

    Since OpenSSH added FIDO2 and it’s in OpenBSD by default, I have completely switched to using it.. and I have to say it’s painless!

    I even did a writeup showing how to use two different keys (resident and non-resident) on the same device: https://deftly.net/posts/2020-06-04-openssh-fido2-resident-keys.html

    1. 2

      Since OpenSSH added FIDO2 and it’s in OpenBSD by default, I have completely switched to using it.. and I have to say it’s painless!

      I want to use it. But as far as I understand, GitHub and others do not support it yet, right?

      1. 2

        Ya, last I tried it didn’t work on GitHub. They always lag behind pretty bad with regard to OpenSSH features.

        1. 1

          I’m confused, isn’t this a client-side OpenSSH feature? Shouldn’t GitHub be agnostic to whether the key lives on a FIDO2 device?

          Is it a matter of GitHub not supporting the ed25519 key type?

          1. 2

            The FIDO stuff is a new key type: ed25519-sk

    2. 4

      I found that managing yubikey ssh identities with gpg-agent was painless. I’ve never encountered issues with the agent forgetting the key, though I have a gpg-connect-agent updatestartuptty /bye in my shellrc file.

      1. 2

        I mean, if it works for you, great! My experience with most of the gpg stack has been mostly negative, mainly because of the “jack of all trades, master of none” effect: gpg tries to support all the key types, ways of connecting to smartcards (directly and via pcscd), … – and at least for me, seems to suffer in usability as a result (too many moving parts and things that can go wrong). I think my machine has about 3 different types of GnuPG keyring, managed by different pieces of software (GNOME Keyring, pacman, gpg-agent itself, …). When it works, it’s great, but when it breaks…

        The PIV solution is interesting in that it seems to be much better designed (in contrast to the GPG API which is a complete tire fire, as far as I understand it) – and yubikey-agent seems to be a relatively simple Go app that just proxies authentication/signing commands through to pcscd and back.

        1. 1

          I didn’t mean my comment as a dismissal of your article. I was just offering an alternate point of view on using the Yubikey with plain GPG. :)

      2. 1

        Using yubikey-agent is not necessary, you can simply add the OpenSC PKCS#11 plugin to the OpenSSH agent instead: ssh-add -s /usr/lib/opensc-pkcs11.so. This will directly prompt for the PIN and thus might be a bit more inconvenient than yubikey-agent.

        1. 1

          Interesting that this claims a maximum number of 8 digits. I have a yubikey 4c nano holding a gpg-agent based key with a 30-digit PIN. (I hope!)

          1. 4

            What happens if you try to activate the key using only the first 8 digits?

            1. 1

              Interesting – I didn’t realise the gpg-agent-based solution had better PIN support in that regard! Personally, my PIN is rather short; given that it’s not directly encrypting anything (and the hardware enforces a lockout after 3 failed tries), I don’t think this is the end of the world :)