Your Yubikey (but not Yubico's cheaper Security Key product and the dozens of other similar cheaper products) is able to do public key signatures exactly like the ones SSH supports anyway, so GitHub didn't do anything to support those.

But modern OpenSSH can do FIDO, the same technology that drives U2F and its replacement WebAuthn, and is in all those cheaper and more popular products. FIDO won't sign arbitrary data with keys, it will only perform a very specific operations and so OpenSSH grew a whole separate set of public key authentication types to support that approach, and GitHub is announcing their support for these extra types.

There are some neat features beyond "this makes cheaper devices work" but GitHub mostly does not use them, although they do choose to require that your Security Key verify you are present (typically by touching a sensor or clicking a physical button) whereas your existing Yubikey setup might not be doing that and GitHub can't force you to.

Another big benefit is ease of use setting up the Yubikey. My understanding is that these newer key types can be generated very easily using the ssh tools which already exist on your systems. Previously, it was very common to set up GPG keys and integrate them with SSH, which is not only more work but also fairly involved.

These new key types make it a lot easier to get up and running with storing your SSH key on your Yubikey. I would have used this format instead of GPG when I was setting up a Yubikey a month ago, but GitHub (and some other providers I use) didn’t support a new enough OpenSSH version.

I believe this adds support for the new -sk key types, in which the ssh server checks the presence of a U2F token on the client, rather than using something like gpg-agent to effectively store your SSH keys on the Yubikey.

GitHub now supports ecdsa-sk and ed25519-sk type keys. OpenSSH have supported those keys since 8.2, but GitHub has not until now.

With the -sk keys, you no longer need to install any software (gnupg, pinentry, yubikey CLI etc.), or run gpg-agent which has always had reliability issues etc. It should all Just Work out of the box now. GitHub was the last piece of the puzzle for us, and for example I can now change our team's onboarding docs from "follow this long OS specific guide to setup SSH w/ gnupg and ykman" to "run ssh-keygen -t ed25519-sk".

There's some confusion in this thread, but you can use ssh-keygen to generate either a public and private key pair, with the private file being a stub and the validation still happening on your physical YubiKey, OR you can omit the private key stub entirely with "-O resident" option to ssh-keygen allowing you to add your key to your ssh agent on any machine you plug it in (for good and bad).

Not always. On some systems (Fedora 34 in my case) you still have to install FIDO2 package (on Fedora, it's called fido2-tools), otherwise the ssh-agent will not able to function with the -sk keys ("agent refused operation" error message). I did not have to install any extra tools on the target system though.

Yeah, I'm confused as well. I've been using my yubikey for ssh auth for years now with github and other services.

Looks like they added the "-sk" options to Git Bash for windows. That seems to be what they are promoting for the most part with this post. Though the title is a bit deceptive.