How to use FIDO2 USB keys with SSH


147 points | by stelabouras 11 days ago


  • spiridow 11 days ago

    I'm really excited to see more and more people talk about FIDO2. If you're interested about this topic, I gave a talk about it yesterday:

    • jjoonathan 11 days ago

      Here's a browser compatibility matrix (I know, OP is about SSH).

      FIDO2/U2F Just Works in:

          Chrome on Windows
          Firefox on Windows
          Chrome on Mac
          Firefox on Mac
          Chrome in Ubuntu 20
          Firefox in Ubuntu 20
      Wall of shame (FIDO2/U2F does not Just Work in):

      EDIT: it does work out-of-the-box in Ubuntu 20, my bad.
      • conradev 11 days ago

        I've been using my YubiKey 5Ci in Safari on macOS and iOS since macOS 10.15[1] and iOS 13.3[2] (which came out several months ago), and Safari supports FIDO2 + WebAuthn just fine.



        • jjoonathan 9 days ago

          Confirmed, WebAuthn works on Safari, MacOS 10.15.5, and .

          My mistake was to assume that AWS saying "Your browser does not support U2F security keys." meant that Safari didn't support U2F keys. Given AWS's well-earned reputation for half-assing things I really shouldn't have trusted their assessment, but I did. My bad.

        • tialaramex 11 days ago

          In a browser what you want is WebAuthn, U2F is an older never technically standardized hack and should not be used for new implementations.

          New web sites should do WebAuthn to enable this functionality, here's a guide someone else wrote that I found helpful in talking about the moving parts to actually implement this:

          Firefox's WebAuthn implementation isn't as complete as it would ideally be, but it does have a nice feature of asking the user whether to give out the somewhat privacy-infringing "attestation" from a FIDO2 device when it is requested by a web site. IMNSHO ordinary web sites, especially where a second factor isn't even mandatory, should not be asking for attestation and I always refuse.

          • lxgr 11 days ago

            Care to elaborate how attestation is privacy infringing?

            As far as I understand, private attestation is a specific design goal of WebAuthN, achieved by either sharing an attestation credential with at least 100 000 instances of a given authenticator or via cryptographic means.

            There have been instances of authenticator vendors getting this wrong, but I remember reading that browsers will detect it and strip any attestation response in this case.

            • tialaramex 11 days ago

              Not everybody is comfortable that 100 000 is enough.

              Is that extreme? Yes, but the upside to giving out attestation data just isn't there in most scenarios. It's like I have to step over broken glass to get a stale bagel. Yes these boots mitigate the risk from the glass very well but I don't even want a stale bagel anyway.

              There are some scenarios where attestation makes sense. If you issued every one of your employees a genuine Yubico Yubikey then I guess it could make sense to insist on checking with attestation that nobody is using some homebrew device they built instead. But for general use? Even the tiny risk isn't justified, so it should be "off".

              Here's someone much smarter than me proposing something you could do if you really care about the features from attestation but don't want people to give up privacy. If you insist on offering stale baked goods, here is how to clear up that glass:


            • StavrosK 11 days ago

              Oh is that what the "anonymize this key" is? If the website requires attestation, authentication might fail, but no website should require attestation, maybe unless you explicitly got the key from them (like a bank).

              • lxgr 11 days ago

                Websites should absolutely be requiring attestation.

                The attack scenario here is malware on your computer pretending to be a hardware authenticator (during sign-up or 2FA enrolment) but really just emulating one in software.

                • tialaramex 11 days ago

                  In this scenario bad guys are currently authenticated as you (otherwise they can't do enrolment) and can do whatever they want but, perversely, they decide what they want to do is... obtain the ability to authenticate as you later in a traceable way. I don't buy it.

                  If you're a James Bond villain and the plot's resolution needs to be saved for the final reel then this makes sense, you can't blow up the world 40 minutes into the story 'cos the audience knows that isn't the end. But real crooks don't want to build suspense, they're going to jump to the part where they win. Why play this long game?

            • StavrosK 11 days ago

              "Passwordless" mode unfortunately doesn't work for me in Firefox, I implemented it on but I'm not sure if I did something wrong. Chrome works fine, though.

              • seqastian 11 days ago
                • lxgr 11 days ago

                  It already works with external FIDO2 compliant authenticators on Safari 13 (iOS 13.5 and macOS 10.15.4).

                • xenophonf 11 days ago

                  I haven't had any problems using my Yubikey in U2F or PIV modes on Ubuntu 20.04.

                  • jjoonathan 11 days ago

                    Confirmed and updated, thanks!

                    The fact that it didn't work out-of-the-box in Ubuntu 19 (needed a udev tweak) and a failing USB port on my laptop gave me the impression that it also didn't work out-of-the-box in Ubuntu 20 (which I booted from a USB key, hence the good port was unavailable), but I just tried it using my laptop's good USB port and a hub and I can now confirm that it works out-of-the-box in Ubuntu 20.

                  • microcolonel 11 days ago

                    Just Works in Chromium and Brave on Arch Linux.

                    • jjoonathan 11 days ago

                      With or without udev tweaks? That has been the major caveat on linux in recent times.

                      • microcolonel 11 days ago

                        I have no personal udev rules for my Yubikeys, just whatever ships with Arch.

                  • StavrosK 11 days ago

                    That's very useful, thank you! I've been looking for something that goes into a bit more detail, so your talk is timely.

                  • DCKing 11 days ago

                    EDIT: I misunderstood the post, and what I describe below is not true!

                    I'm incredibly excited about FIDO2, but this is quite underwhelming honestly. I'd like to SSH with a credential on my Yubikey, not by a credential or configuration already stored on my computer that is unlocked by my Yubikey. I'd like to be able to plug in my Yubikey anywhere and go. My Linux desktop, my Macbook, my Windows desktop, my Android phone.

                    - Yubikey with GPG/PIV for SSH: your Yubikey stores your private key. You can take it anywhere, plug it in, [have to go through all the setup required for your computer to talk GPG/PIV], and log in.

                    - Yubikey with FIDO2 for SSH: your Yubikey stores a symmetric key to unlock your private key on your computer. [You cannot take it anywhere], plug it in, don't have to set anything up if your client and server have this (eventually), and log in.

                    FIDO2 is solving a lot of authentication convenience problems, but not this one I think. I get that this pretty nice when integrating with Windows Hello or Apple's TouchID, but I don't think FIDO2 USB key with SSH is that great.

                    • StavrosK 11 days ago

                      You misunderstand how FIDO2 works. Read the article, it details how to do exactly what you say it can't. You can resume your excitement now!

                      • DCKing 11 days ago

                        In that case I'll need to update my understanding, but this still requires you to do manual configuration for your SSH key - the id_mykey_sk file in your example.

                        > ssh-keygen -t ecdsa-sk -O resident -f ~/.ssh/id_mykey_sk

                        I know this is just a reference, but it's still manual configuration. On a host with an SSH client that can speak PIV [this is a challenge], I can just plug in, enter the PIV PIN code, and go.

                        • StavrosK 11 days ago

                          Read farther down, you don't need this key, you can delete it if you want. You'll just have to run `ssh-add -K` every session if you do, so your agent reads the key from the device.

                          • DCKing 11 days ago

                            Ah I missed that. My apologies, I learned something new!

                            • StavrosK 11 days ago

                              No problem, it's a fantastic way to use SSH, I'm just glad it exists.

                      • traceroute66 11 days ago

                        "Yubikey with GPG/PIV for SSH"

                        There's no need to mess around with the GPG side of the Yubikey to get SSH working. Just the "plain" side of the Yubikey will work (which is great on a Mac because all you need is the basic dylibs - downloadable from Yubi and easily mv/cp installable in the relevant lib dir - rather than needing to mess around installing gpg). Added bonus is you enforce touch for key usage.

                        • DCKing 11 days ago

                          Yes, that's the PIV applet.

                        • notaplumber 11 days ago

                          You can, that's exactly what resident keys in this article is referring to.

                          Once all of those platforms have a more recent OpenSSH, you can ssh-add -K to add keys to your SSH agent.

                          • DCKing 11 days ago

                            I fully understand what kind of credentials FIDO2 can store - but as I read it this still requires manual configuration on individual devices.

                            • notaplumber 11 days ago

                              Nope. It's in the article. Just insert the key and ssh-add -K. I wouldn't be surprised if other SSH agents (e.g. Apple) added a UI to do this.

                        • ptspts 11 days ago

                          I managed to make this work today as described in the article, after installing and configuring the software dependencies.

                          Client-side hardware dependencies:

                          * USB token with U2F (FIDO) support. FIDO2 is optional. Any old YubiKey or similar will work.

                          * For the resident key feature only: USB token with FIDO2 support.

                          * To avoid confusion, only a single USB token should be connected when ssh-keygen is run. (When ssh is run, multiple USB tokens work, the user can touch the wrong one many times, and authentication succeeds after the user touches the right one.)

                          * ED25519 support in the token is optional. (`ssh-keygen -t ecdsa-sk ...' uses the NIST P-256 curve, which works with all U2F tokens.)

                          Client-side software dependencies:

                          * For communicating with the token over USB, OpenBSD or (Linux with udev).

                          * OpenSSH 8.2p1 or later.

                          * OpenSSH client (ssh) compiled with `configure --with-security-key-builtin'. Without this, eventually authentication will fail locally with `internal security key support not enabled'. It's possible to work around this by compiling an .so file and specifying it with `ssh -o', but it's complicated.

                          Server-side software dependencies:

                          * OpenSSH 8.2p1 or later.

                          * Default OpenSSH server (sshd) settings (without PubkeyAcceptedKeyTypes), or PubkeyAcceptedKeyTypes in /etc/ssh/sshd_config containing and (optionally, for ed25519-sk keys) .

                          • ptspts 10 days ago

                            FYI Another client-side software dependency: libfido2 >=1.3.0. It doesn't work with libfido2 1.2.x or earlier.

                            Also, if it doesn't work on your client system only because OpenSSH 8.2 was compiled without `configure --with-security-key-builtin', here is how to make it work:

                          • michaelt 11 days ago

                            > be extra careful when using SSH forwarding (the -A option), as the server can then ask your computer to authenticate to other servers on your behalf.

                            That would require an extra press of the token's button for each extra authentication, right?

                            • StavrosK 11 days ago

                              That's a good point, I haven't tried it but I think you're right, which is another great benefit of using hardware tokens.

                              • staticassertion 11 days ago

                                I would assume the agent caches the key for signing.

                                Would someone please confirm this? If it did require another key press that would be pretty huge.

                                • tialaramex 11 days ago

                                  > I would assume the agent caches the key for signing.

                                  For that to happen the agent would need to have some way to get the key out of the FIDO authenticator, which is deliberately not intended to be possible. I will now go away and confirm that this behaves as I expected and update this message shortly.

                                  Update: Yes, the OpenSSH agent just has code to go talk to the authenticator each time it needs to sign something. The authenticator may or may not (most seem to not) allow this to happen without verifying user presence (e.g. via a button press or touching a contact) but even if your device does allow this the signed payload says whether the user was present, so a remote SSHD can (if it wanted) demand to see signed evidence of user presence or refuse login, and I think a SSH agent can't fake that without help from the FIDO authenticator itself.

                                  • jlgaddis 11 days ago

                                    > ... so a remote SSHD can (if it wanted) demand to see signed evidence of user presence or refuse login, ...

                                    I'd like to be able to, server-side, 1) require that the private key used for authentication be stored on a hardware device and 2) require user presence, but I've never read or heard that this is possible (granted, I haven't looked into too much).

                                    If you have links to any documents that discuss how to implement this, I'd appreciate you sharing them. The only relevant documentation I can find is regarding FIDO/U2F support and even the release notes for 8.2 mention that "OpenSSH does not currently make use of this [attestation certificate]".

                                    • tialaramex 11 days ago

                                      So there's two parts, let's take them separately.

                                      > 1) require that the private key used for authentication be stored on a hardware device

                                      So for this you're going to need the attestation data, which as you observe OpenSSH currently doesn't do anything with. It is willing to stash it in a file, and because it's a certificate it's safe for the token's owner to send this somewhere. So you could construct a mechanism to examine the attestation file and decide whether to accept the proffered public key based on that attestation. e.g. "This is a genuine Yubikey 5C, so OK" or "This is a Crap Corp Funky Fake, no thanks".

                                      I expect this would be a bunch of work, and I don't expect Free Software people to help build something to do it any time soon. But from what I can see it's possible with the components that already exist. Maybe somebody who really wants this will do all the work and put it on GitHub.

                                      > 2) require user presence

                                      The FIDO "options" bitflags have a flag for "user presence" (sometimes labelled UP). If this isn't set, user presence was not checked by the authenticator.

                                      The FIDO authenticator includes this options parameter as part of the message it's signing.

                                      So this means if a SSH client/ agent sends you an options field with UP set, but actually user presence wasn't checked it won't be able to provide a signature that matches. The SSH server doesn't need to do anything special except look at the UP bitflag if it cares (all WebAuthn servers are required to check this, it's on the long list of steps to perform WebAuthn authentication properly).

                                      To be fair this isn't OpenSSH (though I'm sure they have at least somebody paying attention) it's FIDO itself that designed the signatures to also sign the user presence indication, they couldn't have avoided it.

                                      • jlgaddis 11 days ago

                                        > I expect this would be a bunch of work, and I don't expect Free Software people to help build something to do it any time soon.

                                        That's basically the conclusion I ended up at but I was hoping you were aware of some recent progress that I didn't know about! Thank you, though, I certainly appreciate the response.

                                    • staticassertion 11 days ago

                                      Oh duh, of course. Yes please confirm! Super eager to hear if this is the case.

                                  • mightybyte 11 days ago

                                    It depends on how you configured your Yubikey. I believe you can configure it both ways.

                                  • graton 11 days ago

                                    I was able to get this going, but it took awhile as I use a non-standard working mode.

                                    All of the docs I have read assume that you are logged in locally on the system, but if you are not (like me) then things fall apart.

                                    I am running a Windows 10 desktop, and then SSH into my local Linux box from Windows. Both systems are sitting next to me and I can press the Yubikey easily.

                                    My local Linux system is running Fedora 32 and I did the following to enable a user connected via SSH to use the Yubikey.

                                    Created a user group for yubikey users, which in reality only has me in it.

                                    Created a /etc/polkit-1/rules.d/99-pcsc-yubikey.rules file which gives smartcard access to the 'yubikey' group. Without this then 'ykman list' would not work.

                                    Created a /etc/udev/rules.d/99-yubikey.rules to give access to the 'yubikey' group. I used /lib/udev/rules.d/69-yubikey.rules as the starting point for my file. I had to add my two Yubikeys USB IDs (lsusb to see them) as they weren't present.

                                    Made sure to log out and back in to have the 'yubikey' group be active for my user. I vaguely remember a command that would do it, but I forgot it.

                                    After all of that I got it to work :)

                                    • simias 11 days ago

                                      I've been using my Yubikey in GnuPG smartcard mode for years to do the same thing, from what I can see from this tutorial FIDO2 seems a bit easier to setup initially but it also seems much less widely supported at the moment. Are there other tradeoffs to consider?

                                      • StavrosK 11 days ago

                                        I think those are pretty much the only ones, the Yubikey in GPG smartcard mode was always too fiddly for me and interfered with my agent in other ways, but this is trivial to set up and use.

                                        Also, a big draw of the USB SSH key for me is that I can plug it in to other computers and connect to my servers, which smartcard mode didn't do, so that was a big drawback for me.

                                        • simias 11 days ago

                                          Yeah fiddly is the right word, although once the painful initial configuration is done it generally works fairly well in my experience.

                                          Being able to easily migrate to a new computer sounds like a great feature though.

                                          • RL_Quine 11 days ago

                                            You can't do that easily, you still need the public key file on disk.

                                            • StavrosK 11 days ago

                                              Not with resident key mode.

                                              • RL_Quine 11 days ago

                                                Sort of. The keys have limited space on them (20 for some Yubikey models) for resident keys. You wouldn't want to be always using them for everything.

                                                • StavrosK 11 days ago

                                                  That's why I'm excited about SoloKeys v2, they (will) come with space for thousands of resident keys.

                                          • OJFord 11 days ago

                                            You can use an OpenPGP card more generally than just for SSH auth.

                                            E.g. other auth, and GPG encryption - such as with `pass`.

                                            • tialaramex 11 days ago

                                              Going FIDO-SSH can perhaps be cheaper than PIV, especially if, as we very much want, FIDO is popular which will tend to drive down prices.

                                              Cheaper/ simpler FIDO2 products (from Yubico) exist if this feature is the only thing you want from a Yubikey. I don't know if that's a future Yubico are enthusiastic about, but I don't see much reason to hate it as an end user.

                                              Even cheaper and even simpler FIDO products (from many vendors) exist if you only ever actually want this from one or two systems (e.g. a laptop and then one desktop workstation) so you don't need resident keys because the "non-resident" part lives on your workstation.

                                              • simias 11 days ago

                                                I always assumed that the relatively high price of the Yubikey had more to do with it being a relatively niche product than the cost of production, after all it's not much more than a cheap microcontroller underneath all that.

                                                Was I wrong to make this assumption? Why would FIDO tokens be significantly cheaper and/or more popular?

                                                If anything it seems like at first it's going to fragment the market even more.

                                                • tialaramex 11 days ago

                                                  A full-blown Yubikey has modifiable firmware and a relatively large amount of rewritable Flash storage. I assume those features aren't free.

                                                  A FIDO authenticator has no modifiable state beyond maybe some sort of counter, it has a random secret key which makes it unique from its siblings, and that's it. No firmware update feature, no storage.

                                                  The crypto hardware is also simpler. FIDO was defined in terms of these nice compact elliptic curve schemes. The keys are small, the operations are simple, I'd be surprised if dedicated silicon to implement this isn't cheaper, and if you're just running it on a cheap microcontroller I'd be surprised if you can't get away with a cheaper microcontroller than you would need to implement RSA encryption and whatever else a Yubikey can do.

                                                  Finally in terms of volume, it makes sense to give all your 5000 staff a FIDO key. "Go to the enrollment page we built by this Friday. Enrol your FIDO key. Call the help desk if you have problems. From next Monday these are mandatory". You can lock down common corporate web SSO solutions with it for example, outfits like Duo will let you just check one box and you can now answer "Yes" to pages of questions your CISO is supposed to fill out every year.

                                                  It doesn't make sense to give out 5000 traditional Yubikeys. A dozen to a dev team for PIV? Maybe. But the lady who does 2.5 days per week in the accounts department? She doesn't need PIV. She can use a FIDO key to sign into the accounts web app though.

                                                  • crote 11 days ago

                                                    That's not really true anymore. Yubikeys haven't supported firmware modification for years due to security reasons, and FIDO2 keys often have storage in order to support Resident Keys.

                                                    • tialaramex 10 days ago

                                                      I was not aware that Yubikeys no longer can be firmware updated. My impression was that they just don't permit user firmware modification by policy but that is clearly wrong.

                                                      FIDO Security Keys are cheaper than FIDO2 Security Keys which is what I'd expect from what I wrote, they don't need any storage.

                                              • acdha 11 days ago

                                                If it's been stable for you, that definitely works well but I found OpenSC to be unstable and required hotplugging the device and/or killing gpg-agent on a regular basis.

                                                Mac users do have built-in support which works the same way with certificates and is more stable in my experience:


                                              • dboreham 11 days ago

                                                I've waited 10 years for this.

                                                • StavrosK 11 days ago

                                                  Same here, and I just absolutely love how well it works. Now if Android SSH apps add support for it, my SSH life will be complete.

                                                  • ta17711771 11 days ago

                                                    Can you do it with Termux or T-UI somehow? Addons?

                                                    • StavrosK 11 days ago

                                                      Hmm, I don't think so, but I'll look into it, thanks!

                                                  • xaduha 11 days ago

                                                    Should've asked around, there were devices, standards and software for this kind of thing for a while e.g.

                                                    • knorker 11 days ago

                                                      Waited 10 years? Why didn't you just use a yubikey in PIV mode, or the yubikey with gpg, or a smartcard, or… I've been using a yubikey PIV for, hmm… at least 5 years.

                                                      Sure, a FIDO key is cheaper.

                                                      • xaduha 11 days ago

                                                        BTW both PIV and GPG in Yubikeys are just applets and not particularly suited for SSH use either. Proper applet for it is this one, if you can install it of course.

                                                        Some get confused or have bad associations when hearing the word 'applet', but that is what they are, as in 'Java applet'.

                                                        This one is too

                                                        • knorker 11 days ago

                                                          What makes you say it's not particularly suited for SSH?

                                                          • xaduha 11 days ago

                                                            Because they were made for a different purpose, with extra hoops you need to jump through.

                                                            • knorker 10 days ago

                                                              U2F was made for a different purpose too.

                                                              I don't see what's so extra hoop-y about telling SSH "use key from industry standard PKCS#11". That's literally what it's there for, and when Yubico added PIV support that instantly added support to multiple operating systems (incl Linux & Windows) where SSH keys "just work".

                                                              I can take a yubikey today from my Linux system, plug it into a Windows machine, and Putty with wincrypt support "just works". Because that's how it was designed.

                                                              • xaduha 10 days ago

                                                                You're using yubikey agent or ykcs11 or yubico-piv-tool or somesuch nonsense most likely that actually provides PKCS#11. That is it wraps whatever PIV is supposed to do and gives you PKCS#11 interface. I'm talking about something that isn't Yubico specific and provides PKCS#11 and PKCS#15 with OpenSC straight ootb.

                                                                e.g. issues that described here are avoided

                                                                • knorker 10 days ago

                                                                  I'm using opensc straight of the box, with vanilla SSH. I am using ssh-agent, but it works just as well without it.

                                                                  I can pop my yubikey into a plain vanilla install of Linux and run "ssh -oPKCS11Provider=/path/to/".

                                                                  Or just put this into your ~/.ssh/config

                                                                  Host *

                                                                    PKCS11Provider /path/to/
                                                                  Or on a Windows plain vanilla system I just pop the key in and tell putty-cryptoapi to use "the smartcard key". Windows pops up my pinentry dialog, then I touch to verify physical presence, and in I go.

                                                                  I agree that the gpg-agent way is yuck. But I still don't understand what you mean about the PKCS#11 way though. Yes, setting up the key required yubico tooling. Is that what you're talking about?

                                                                  • xaduha 10 days ago

                                                                    I never owned a yubikey and things probably changed over the years also since I last looked into it. But even so what you have there is a proprietary applet with lots of extensions

                                                                    If it works with OpenSC out of the box, then that's because Yubico made it to work. I pretty sure that if you tried to use a publicly available PIV applet that does its PIV duties in accordance with the specs you are not going to have a good time trying to pair it with OpenSSH.

                                                                    • knorker 10 days ago

                                                                      Well… do you still say that it's not particularly well suited, then?

                                                                      If yes, then why?

                                                                      • xaduha 10 days ago

                                                                        Decide for yourself, PIV is an old and sprawling monstrosity and if you go from the specs, then no, it's not particularly suited for this relatively simple task. Proprietary PIV applet made by Yubico might be, but is that a good thing? Not in my book when they easily could've done what Philip Wendland did there with IsoApplet, having several applets and switching between them is basic stuff.

                                                        • closeparen 11 days ago

                                                          OpenSSH doesn't do X.509, how would PIV mode or a smartcard help?

                                                    • j88439h84 11 days ago

                                                      Is this instead of typing a password to unlock the ssh key?

                                                      • Freak_NL 11 days ago

                                                        If you wish. You can decide if you want a passphrase on the generated key or not, just as you can with a classic SSH key. It's probably best to use a passphrase and have ssh-agent remember it for you until you shut down the computer. That way you enter your passphrase the first time using SSH with that key after logging in, and ask you to tap the physical U2F key, and only ask for the interaction with the physical key afterwards.

                                                        When I SSH to a host configured like this, the Yubikey U2F key I am using blinks to ask me to touch it. It's really quite neat.

                                                      • decentralbanker 11 days ago

                                                        been looking forward to seeing FIDO gain traction for more use cases. i interviewed at a company where there's work being done on a FIDO-enabled smartphone approach:


                                                        • Bedon292 11 days ago

                                                          Am I missing something? The commands for resident and non-resident appear to be identical.

                                                          Edit: They fixed it.

                                                          • arianvanp 11 days ago

                                                            they have the addition of -O resident

                                                            from ssh-keygen:

                                                                          Indicate that the key should be stored on the FIDO authenticator itself.  Resident keys may be supported  on
                                                                          FIDO2 tokens and typically require that a PIN be set on the token prior to generation.  Resident keys may be
                                                                          loaded off the token using ssh-add(1).
                                                            from ssh-add:

                                                                    -K     Load resident keys from a FIDO authenticator
                                                            • StavrosK 11 days ago

                                                              I had the same command in both by mistake :/

                                                            • nobodyshere 11 days ago

                                                              Can't make that part work on Mac.

                                                              • StavrosK 11 days ago

                                                                Unfortunately, MacOS still ships with SSH 8.1, AFAIK.

                                                                • nobodyshere 11 days ago

                                                                  I installed 8.3 through homebrew but its agent just doesn't allow me to do that. Also can't ssh-add an sk key.

                                                                  • StavrosK 11 days ago

                                                                    Hmm, are you sure you aren't calling the agent of the old one?

                                                            • StavrosK 11 days ago

                                                              Sorry, copy/paste fail. Fixed now, thanks!

                                                            • indigodaddy 11 days ago

                                                              @StavrosK do you have a writeup on how you put together your blog infrastructure?

                                                              • StavrosK 11 days ago

                                                                Not really but it's just Lektor and Netlify, hosted on Gitlab. I also have Gitlab CI deploying the site on Neocities ( as a backup/just to see if I could.

                                                              • RL_Quine 11 days ago

                                                                Be aware literally nothing supports this unless it's your own kernel.

                                                                Gitlab? No. Github? No. My gateway with a hand built gentoo kernel? Yes.

                                                                It seems functional, but you've also got to be aware that `ed25519-sk` and `ecdsa-sk` have sort of spotty support in the devices too. `ed25519-sk` does not work on a Yubikey <5, for example.

                                                                • StavrosK 11 days ago

                                                                  > Be aware literally nothing supports this unless it's your own kernel.

                                                                  Ubuntu 20.04 and later supports this, and, since that's LTS, it means that quite a few servers and machines will be supporting it already.

                                                                  Github/Gitlab aren't supporting it yet, but given how great it is for security, I think they have a big incentive to speed up support.

                                                                  > ed25519-ek does not work on a Yubikey <5, for example.

                                                                  That's no problem, since you can just generate an ECDSA key instead, but yes, not all keys have hardware support for all algorithms.

                                                                  • Freak_NL 11 days ago

                                                                    Debian 11 too, out of the box. It took a bit of work to use a newer openssh-client on my Ubuntu 18.04 laptop, but that was manageable.

                                                                  • nobodyshere 11 days ago

                                                                    Not exactly true. Ubuntu 20.04 supports this out of the box and lots of VMs therefore also do.

                                                                    • knorker 11 days ago

                                                                      Not only that, but there's billions of devices out there that don't support it.

                                                                      I can SSH to my AP, my home router, all routers at basically any ISP. None of those support this. Most of them probably never will, until they're thrown away and new ones bought in 5-10 years.

                                                                      Bottom line: This can't be your only key. So why bother? Why not use PIV mode/smartcard/other, which does work with every single one of these billions of devices, because they have no server-side requirements like these.

                                                                      • ptspts 10 days ago

                                                                        Here is another tradeoff. Many PIV smartcards (such as YubiKey 4, if I'm not mistaken) are able to store only a single private key. With U2F (ecdsa-sk), the number of SSH keys is unlimited.

                                                                        Another tradeoff. Some users may be using a cheap or old token (without PIV support) or a token with a private key slot already used for something else. Now, with a software-only upgrade (on both SSH client and server), they can user their existing token for SSH authentication.

                                                                        • knorker 10 days ago

                                                                          Ah yes, that's a good point. It is not great that you leak your identity by using pubkey (ssh