1. 50

  2. 10

    I’ve been using this since it was merged into OpenSSH, and can confirm how well this works.

    It is quite refreshing compared to using gpg, which required 3 (!) daemons to work. You had to run a gpg-agent in ssh-agent mode, which spawned its own scdaemon, which communicated with pcscd (which you had to start yourself), which dynamically loaded a CCID module, which used libusb to finally talk to your device.

    I saw that OpenSSH also supports ed25519-sk keys. Do you know which security key models support this? I have a super old Yubikey NEO (U2F only) and a Solo key, and neither of them do. Perhaps one of the newer Yubikey models?

    1. 7

      It looks like YubiKey firmware v 5.2.3 from January 2020 includes curve 25519 support; it’s not clear to me if you can get this on the U2F-only models.

      1. 1

        Thanks for the link. It sounds like any recent YubiKey 5 series should have this support.

        The U2F protocol is specified to use P-256 keys[0], so you’d definitely need a FIDO2-capable device.

        [0] https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-raw-message-formats-v1.2-ps-20170411.html#registration-messages

      2. 2

        You could already use many YubiKey’s PIV application with OpenSSH through the OpenSC PKCS#11 support [1]. Since some recent version of OpenSSH (8.0 IIRC), you could also use some elliptic curve keys through that route.

        The U2F key support is cooler, because the keys are much cheaper. However, the PKCS#11 route has the benefit that it also supports authenticating with servers that have older OpenSSH versions, whereas the U2F support also requires that a server is on OpenSSH 8.2.

        [1] https://developers.yubico.com/PIV/Guides/SSH_with_PIV_and_PKCS11.html

        1. 1

          I only have to run gpg-agent on my Mac to use my Yubikey as an ssh key. I don’t manage any other daemons. Everything just works.

          1. 2

            This is because macOS is always running a smart card services daemon, to support e.g. logins with a smart card and code signing with smart cards. So on the Mac only gpg-agent and scdaemon are needed, which are automatically started by gpg.

        2. 4

          Does this still let you require that you must touch the Yubikey to use it? That’s the only safe way to use SSH agent forwarding

          1. 2

            I just tried it and yes, it does.

          2. 3

            Just to check, does this mean we can skip passphrases for the ecdsa-sk keys? ssh-keygen still asks for one, but assuming I’m comfortable with the security model of Yubikey possession == access, is a passphrase still necessary?

            1. 2

              Yep, even without a passphrase for most tokens it’s still private key file + hardware token. With a passphrase it should be private key file + passphrase + hardware token. With resident credentials it’s just hardware token.

              1. 1

                Awesome, thanks for confirming Filo!

              2. 2

                To answer my own question: all I had to do was read past the first half of the article.

                • Without a passphrase, authentication requires possession of at least the the hardware token. If the hardware token is implemented well, it also requires the possession of the private key file.
                • With a passphrase, authentication might require the passphrase and private key file. If the hardware token is implemented well, authentication requires the passphrase, hardware token, and private key file.

                So in both cases access implies possession of the hardware token, and if I’m comfortable with that being sufficient then I’m free to skip adding a passphrase.

              3. 2

                ssh-keygen -t ecdsa-sk

                Can such a key be “connected” with another hardware token (e.g. if the primary token fails)?

                1. 2

                  On macOS, should you always be installing OpenSSH with Homebrew to get this and other updates? I don’t normally install OpenSSH, but I do use Homebrew extensively for other things.

                  1. 3

                    macOS is at OpenSSH 8.1 so it doesn’t support it and we don’t know yet if they’ll build it with the native support.

                    1. 2

                      Unfortunately installing from Homebrew doesn’t replace the system-provided ssh-agent, so the agent started automatically by the OS won’t be able to load the ecdsa-sk key type.

                      SIP won’t let you modify the /usr/bin/ssh-agent binary nor edit the launchd plist. In theory you could create a new launchd service to run the brew-installed ssh-agent but then you lose Keychain support for the passphrase. Depends if that’s important to you.

                      1. 2

                        Oh, fascinating. macOS does indeed run a default on-demand ssh-agent, and the socket path is magically passed in the environment of login shells. I did not know this! Kinda surprised that Homebrew would ship its own ssh-add by default when again by default it would talk to the system ssh-agent. I wonder what the backwards compatibility of that protocol is.


                        The good news is that if I read this right we’d be able to load the Homebrew FIDO2 middleware into the system agent if they don’t build it.

                        The bad news is that Apple squatted on “ssh-add -K” for keychain support, and now that’s a real option for loading resident keys 🤷‍♂️

                        1. 1

                          The did update the OpenSSH version that originally came with Catalina, 7.9 to 8.1 now. So let’s hope that there will be a 10.15.5 with OpenSSH 8.1.

                      2. 2

                        Thanks for sharing! I’m going to try and get it working with the FIDO2 app on my Ledger Nano S.

                        1. 1

                          Can anyone point me to a good review/comparison of the available U2F keys?