[Rafert]

> If the goal wasn't to require the key file-- why store the key handle there at all and not just derive it from data sent by the server as in a more typical U2F application? The only other advantage I see is potentially limiting some cros-domain attacks (e.g. where server A provides server B's key handle).

I was also a little surprised this isn't used as a second factor, like Universal 2nd Factor is meant to be used. But maybe it's not so surprising given there are at this moment probably more U2F keys than FIDO2 keys in users' hands and the author chose to went with the option that has a bigger installed base.

FIDO2 offers resident keys[0] where a unique key is generated and stored on the authenticator. The server does not need to present the key handle to the authenticator so it can decrypt it and initialize its internal state. The server gets back the userHandle[1] that was set during registration as well.

Protecting the resident credential(s) can be done via a PIN or fingerprint scan, depending on the capabilities of the authenticator and user preference.

[0]: a. https://auth0.com/blog/a-look-at-webauthn-resident-credentia... b. https://www.w3.org/TR/2019/REC-webauthn-1-20190304/#resident...

[1]: https://www.w3.org/TR/2019/REC-webauthn-1-20190304/#user-han...

[LIV2]

You can use it as a second factor by configuring the server to require both password & key with the "AuthenticationMethods" directive

You can also configure it to require public key + U2F by specifying pubkey auth twice which will require two different pub keys but I suppose that would depend on the user having only 1 regular pubkey and one U2F pubkey in their authorized_keys file

https://man.openbsd.org/sshd_config#AuthenticationMethods

[nullc]

> I was also a little surprised this isn't used as a second factor, like Universal 2nd Factor is meant to be used. But maybe it's not so surprising given there are at this moment probably more U2F keys

Even with just U2F, the public key you install on the server could include both the "key handle" and the derived public key... then the ssh client doesn't need to know anything (except perhaps that its should prompt you to use the device).