ronf
Windows fido2 security key non-admin
Hi,
I have a remote access app built as an internal tool and we use fido2 keys to authenticate this connection. However, as one of the primary places to run this is on windows, we require full windows support. Unfortunately, not everyone needing this has access to admin on the PC's - which is currently required to retrieve Fido2 keys on windows.
I believe there is a method of getting fido2 keys without admin on windows, so I'm wondering if its possible for support for this to be added.
Thanks :)
I was able to confirm that FIDO2 keys work with AsyncSSH on Windows, but according to what I've read online, using the fido2 library only works when running at Administrator on Windows 10 & 11. This is true even for Yubico's own management tools. So, unless you can run Python as an administrator, FIDO2 keys aren't going to work on those versions of Windows.
I saw some mentions of new "Windows Hello" APIs that might address this, but I'm not really a Windows person and don't know what it would take to support that. It would need to support very low-level calls (signing arbitrary data with the token's private keys), and it would need to have ways of getting public keys off of the token and enumerating the keys that were available. Also, all of this would need to be available from pure Python code.
I did a bit more digging into this, but it's not looking promising.
On the plus side, libfido2 does actually now have code in it specific to Windows which allows you to go through the native Windows webauthn APIs and access a FIDO security key without being an admin. However, those APIs are designed to let you enroll a key to access websites. After enrolling a key with a specific site, it is possible to use that enrolled key to authenticate to an SSH server, but there don't appear to be any tools in OpenSSH to create such keys directly, the way you can with regular FIDO keys. Also, there's no client support in OpenSSH to use these keys from what I can see. Right now, they can only be used in something like an SSH client running in a browser. There's also no mechanism to encode the additional fields needed for webauthn authentication into the existing OpenSSH "SK" key types. The browser-based SSH client would have to have its own proprietary way to store this information after enrolling a key.
Given the limitations, I don't think this is something I'd want to try and add to AsyncSSH.
Another update - good news!
I've managed to make a version of the SK "enroll" function which uses the Windows non-admin APIs, and I've gotten AsyncSSH's generate_private_key() function to successfully use this API and generate a key which can be written out as an OpenSSH format "SK" key without being a Windows admin.
I've also managed to make a version of the SK "sign" function which can use one of the above generated keys, and I've gotten that to successfully log in to an OpenSSH 9.9 server without being an admin, once I enabled the webauthn signature algorithm in the OpenSSH server. I had to add the following to the server's sshd_config to get this to work:
PubkeyAcceptedAlgorithms=+webauthn-sk-ecdsa-sha2-nistp256@openssh.com
I've also got this webauthn signature algorithm working on non-Windows systems. The client side uses the existing CTap APIs for doing the signing, but then converts the result into the OpenSSH webauthn signature format when requested. The server side can now verify both the old and new SK signature formats. So, with these changes, it should be possible to log into an OpenSSH or AsyncSSH server from a Windows client using an SK key without running as admin.
I still need to do some cleanup and add in support for things like user presence in the new code, but so far things are looking good!
Support for this is now available in the "develop" as commit e83874a, allowing non-Administrator users on Windows to be able to authenticate with U2F security keys, via the Windows WebAuthN APIs.
In this version of the code, keys do not need to be created on the Windows machine you are authenticating from. You can copy keys between systems and use the same keys for both WebAuthN and CTap-based authentication. This means keys are portable across both Windows and UNIX systems as well.
I have also tested using this new signature algorithm with OpenSSH certificates, and that works too. So, if you have an SK key with an associated certificate, you can use that to authenticate to a server with either the WebAuthN or CTap APIs.
The main limitation at this point is that touch (user presence) is always required when using the WebAuthN APIs. The user will see a pop-up dialog when an authentication request occurs, asking the user to touch the key. Unlike the CTap API, there doesn't appear to be a way to authenticate without user presence in WebAuthN.