Wanted to ask the same. A lot of tutorials still use RSA but I see no reason to use it in 2020. ECDSA keys are supported since an OpenSSL version from 2013.
I still use RSA mainly because Yubikey doesn't support them yet with OpenPGP keys.. I felt the increase in security usage was a worthy compromise to using RSA with a key length that's not yet broken.
I think Fido2 mode does support it but I don't know whether I trust Fido2 fully for SSH.. Especially because it seems to still store a private key locally, which defeats the whole purpose of using a hardware key (I saw this here: https://developers.yubico.com/SSH/ ). The whole idea is to not have the private key anywhere but inside the token itself. It's also a bit early in development where RSA has proven itself. It has some known weaknesses (including high quantum computing vulnerability) but they're well understood.
No, the FIDO OpenSSH support doesn't really store a private key "locally" but I can see why it's confusing. I'll explain.
FIDO was conceived for the Web, and so the SSH authentication model wasn't a core consideration in its design.
In SSH authentication always goes like this:
Client: "I can prove I'm Alice because I can do X"
Server: "OK, do X"
Client: (Proves they are Alice by doing X)
OR
Client: "I can prove I'm Alice because I can do X"
Server: "Not good enough. What else?"
(Repeat with a different method or give up)
Whereas WebAuthn (and U2F and other models FIDO was proposed for) have authentication go like this:
Server: Prove you are Alice, if you are you can do Y or Z
Client: (Does Z)
In FIDO there's a magic "cookie" used, in theory this could be just a "serial number" for a credential, but in reality for a typical FIDO dongle (such as Yubico's Yubikey) it's actually your private key for that site, encrypted using a symmetric key known only to that Yubikey. This way your Yubikey can unlock a genuinely unlimited number of sites, each with completely fresh credentials that can't be correlated, without infinite flash storage. A site says "Here's that cookie you gave me, now prove you're GekkePrutser" and your Yubikey consumes the cookie, decrypts it to get a private key, then uses that private key to prove you're GekkePrutser.
But as we saw in SSH the authentication doesn't happen in that order. The Security Key needs the cookie first, but the remote server is waiting to hear how you'll prove who you are first, it's a stalemate.
To break the stalemate the cookie is stored on your local system, so that can be fed to the Security Key, and then things can proceed.
Down the road apparently the OpenSSH team will add support for FIDO2's "usernameless" behaviour which doesn't need a cookie but does consume limited resources on the Yubikey. If you just can't accept the idea of storing the opaque cookie value because you know it has your private key encrypted inside it, then that mode will suit. It's also useful for "road warriors" who are willing to trust other people's computers briefly but don't carry their own. But that isn't finished today and it seems they don't expect it to be the usual way this is used, since it requires a FIDO2 (not just FIDO) Security Key.
> I still use RSA mainly because Yubikey doesn't support them yet with OpenPGP keys.. I felt the increase in security usage was a worthy compromise to using RSA with a key length that's not yet broken.
