Add support for u2f/fido2 as OpenSSH 8.2 does

[d4g]

With the new option to use Fido2 for authentication, this would be a great alternative to using certificates.

Related release note: https://lists.mindrot.org/pipermail/openssh-unix-announce/2020-February/000138.html

[NoMoreFood]

@d4g If you're aware of any good resources (beyond a simple Google search) about FIDO2 and how it may (or may not) overlap with public key authentication, let me know. PuTTY CAC leverages basic public key authentication within PuTTY to do most of the protocol dirty work so the only way we could reasonably integrate it would be if we can continue to leverage that. Simon (author of upstream PuTTY) refactors things way too often for PuTTY CAC to up with any change that requires us to pass new types of information over the wire.

In principal, I do like the idea though and would be willing to work on it if it can be done using the public key authentication method.

[NoMoreFood]

Researched this a bit myself. It appears like it might be quite an undertaking based on the structure of the messages:

https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.u2f

I'll leave this issue open for anyone that might want to tackle it.

[d4g]

@NoMoreFood it should be nothing more then public key authentication.

As far as I understand, you create a public key/private key pair as you would normally do, but you leverage fido2 to create a combined private key, consisting of a regular key file and a resident key on the fido2 device. The key file will be of a specific format, indicating that it requires a fido2 device as 2nd factor.

Then, when connecting, you have to confirm the fido2 action on your key to allow the usage of the resident key.

This can be done via libfido2 for example, https://github.com/Yubico/libfido2 .

As far as I tested it, the git4windows project already implemented it for openssh on windows using libfido2, but I could be wrong.

[NoMoreFood]

Okay, I'll look into it a bit more.

[matthewlegitt]

If you're looking to add support for FIDO2. send me a PM and we will gladly provide you a coupon code to order some devices for testing.

[t3chn0m4g3]

I would also love to see U2F support.

[kpostekk]

Maybe looking into mgbowen/windows-fido-bridge or tavrez/openssh-sk-winhello would help. As far as I know interaction with U2F key should be done by Windows Hello API.

[velosol]

@kpostekk Nice finds - Looking through those it seems the right path forward is using Windows Hello API (webauthn.h) as libfido2 requires elevated access in order to reach the security key starting in Windows 10 v1903. Compatibility seems good (aside from the known-issue around resident keys stored on the security key device Edit: it's not clear to me if this is an API issue or specific implementation issue). The owner of the second repo is behind the FIDO support in Git for Windows but it seems like that is a work in progress.

Support does not include ed25519 keys through the Window Hello API as noted in the first repo.

OT: This is not really a concern for PuTTY-CAC but more generally I wonder if having a companion GUI app (a la puttygen) would be good for broad adoption as the creation method is currently CLI with OpenSSH 8.2+ ssh-keygen. Most people using this version of Pagaent/PuTTY probably aren't generating their own keys in the first place so not a huge concern, just noting it for anyone looking for a complete guide to use a security key with PuTTY.

[ageis]

Ohh, this one warrants a clear 👍 from me.

[queesamor]

@velosol According to line 578 of his primary source file ( https://github.com/tavrez/openssh-sk-winhello/blob/master/src/winhello.c ), the known issue you mention is in fact an API issue; I should disclaim that I haven't reached out to him to confirm this is current. Be that as it may, this is only something which will affect making "new" Putty-CAC installations (including on new machines) aware of any resident keys which have been stored on a particular FIDO2 key, which is not the default on any openssl implementations I am aware of (including his middleware), although it certainly is convenient. Resident keys, when manually requested at the time of key generation, simply save you from copying the public key file and private key reference-to-fido2-file around to each machine/installation you want to use them with. Although utilizing resident keys is definitely closest to the CAC/PIV experience in terms of cert discoverability, since this isn't the default behavior in openssl, if implemented here the default file/external-key-hybrid configuration will have to be considered as well as the Resident-key configuration.

The effect of this WinHello API hole, only relevant when resident keys need to be accessed once, is temporary: retrieving the list of resident keys on a FIDO2 security key will require a single elevated command directly utilizing the generic libfido2 library, rather than asking WinHello. Of course, if and when MS exposes this via WinHello, that external command can then be rendered unnecessary by reimplementing it via MS's interface.

To your final thoughts about GUI and users of this fork not often issuing their own certs, I believe that the foundations of FIDO2 make it quite unlikely that anyone but the individual user will ever issue and store SSH keys inside their own security key's FIDO2 section, with the possible exception of someone sitting down next to them and doing it with them. FIDO2 is designed from the ground up to not require or make use of any distributed trust model whatsoever, limiting all possible dependencies so that to the user, it just works, and if the destination website loads, the user can expect FIDO2 auth to function, regardless of what infrastructure may or may not be between.

Of course, using FIDO2's ability to generate multipurpose keys on demand, and later sign on demand and attest on demand using those same keys (as we're talking about here) is certainly more in depth than the standard use cases, but FIDO2 is still the framework within which this is happening. I'm not aware of any enterprise-class command/control/policy/enforcement systems aimed at FIDO2 keys themselves. Businesses/DOD can certainly set and enforce policies about how the keys function or can be used within specified equipment, but FIDO2 has as a central goal the prevention of centralized monitoring or control by parties outside the end user, so as soon as the user walks into an internet cafe, the FIDO2 functions of their security key will all perform without constraint, which is quite a bit different than a company/government-issued smart card which may well refuse to perform certain functions if attached to unfamiliar equipment, and so on.

With all of that said, here's my point: I doubt that central authorities of any kind will implement FIDO2 storage of SSH keys very widely, and will rather stick to the fertile lands of CAC/PIV/..... In sharp contrast, end users who don't have a PKI infrastructure to support them will almost certainly do this more and more as the functionality becomes more broadly implemented. In fact, GitHub and Yubikey just announced this functionality across all of GitHub, and GitHub has deprecated passwords for SSH access as a result of this and several other password-replacements becoming widely available.

With my midnight rambling done, I hope this has been more on the helpful end and less the annoyingly aimless end of replies. 😉

[velosol]

@queesamor Quite a bit to go through there! A couple thoughts at least in the context of this repo & issue - I agree that resident keys are very much like CAC/PIV. How popular they end up being will be interesting given the limited capacity of security keys (e.g. 25 for YubiKey 5) although they would be a nice-to-have when you move between machines to reduce the setup required on a new machine.

On the GUI, good point, I was clearly thinking too much from the issued/PKI/derived credential world, any FIDO2-based key restriction would have to come from a business policy point of view as the technical logic isn't present to my knowledge either.

In any case I think a decision on whether to support resident keys (aka discoverable credentials) within PuTTY-CAC would have to be made after they were supported in WinHello - in my opinion, requiring installation of libfido2 (or any other elevation requirement post Win10 v1903) blocks too many people from using it. Whether to support non-resident keys earlier isn't up to me but there's at least everyone who's commented here who are interested!

[RcTomcat1]

I would also like to see this feature :) Just wanted to secure my servers using FIDO2 and was stunned to see that putty does not support it. Looks like all the administrative work will have to be done via my ubuntu vm.

[NoMoreFood]

I plan on revisiting this next month -- hopefully we can accommodate it without a huge amount of changes.

[NoMoreFood]

I should have some sort of proof of concept in a few weeks. Do I have anybody willing to test at that point?

[ghost]

I can do some testing for putty and plink if you will provide test builds (probably I can build them myself, but I don't have env setup at the moment).

P.S. Just tested sk key with recent openssh build 8.9.0.0 from Microsoft - works as expected. To test same with putty I will also need puttygen which understands sk keys and can generate (or better import) them for usage with putty.

[carlreinke]

If anybody's interested, I made an SSH agent that supports using security keys with PuTTY. Currently it only supports security-key-based keys, so it's not a complete replacement for Pageant.

[NoMoreFood]

Thanks @carlreinke!. Given my focus is maximum compatibility, my changes will only support resident keys with ecdsa-sha2-nistp256 so your work will provide a good option for looking for alternatives.

[NoMoreFood]

@astelmachonak-nydig, @d4g, @matthewlegitt, @kpostekk, @t3chn0m4g3, @ageis, @queesamor, @velosol, @RcTomcat1, and others who are interested:

See this branch's binaries. https://github.com/NoMoreFood/putty-cac/tree/fido_dev_branch/binaries

I put most of the FIDO stuff under the current 'Certificate' dialog (even though certificates technically don't play a role with FIDO). There is a key generation utility built into the main PuTTY interface. There is an issue where some cases were dialog boxes have been popping up behind other windows so please be aware of that.

[NoMoreFood]

@astelmachonak-nydig, @d4g, @kpostekk, @t3chn0m4g3, @ageis, @queesamor, @velosol, @RcTomcat1. Anyone happen to have a chance to test this version at all?

[d4g]

I tried it on one system, but got issues with windows hello. As the same issues occur for OpenSSH with fido2 and windows hello on the according system, it seems unrelated. The error message in this cases points out, that the according key cannot be used and one should try another one. I suppose, it's somehow related to a policy. I did not verify it on another system yet.

[NoMoreFood]

Yeah, OpenSSH and PuTTY CAC use the same two main WinHello functions so if it's not working for one, I'd expect it to not work for the other. Did you import an existing key or make a new one? What version of Windows are you running? What make and model of key?

[d4g]

Yubikey 5 NFC: 👍 I could generate ecdsa-ssh2-nistp256 and ssh-ed25519 resident keys with key touch + pin. I did not test the login for ecdsa. For ed25519 I verified that I could login to a system. Windows hello asked for the according pin. Everything worked as expected.

Solo1:👍 Same as above. Worked for ed25519.

Solo2:👎 Does not work. Possibly firmware related?

[d4g]

Mooltipass mini ble:👍 Worked for ed25519 resident key without pin. I think that's a limitation of the platform, as you unlock the whole device with a pin, before beeing able to use it.

[NoMoreFood]

Wow you have quite the array of hardware. I just have my basic Yubikey security key right now. Yeah, my guess would be that the issues are just limitations with the hardware / firmware (or a general incompatibility with WebAuthn in Windows) since the interface is fairly generic. Using a raw USB connection (like what libfido2 can do) might be able to make it work, but I've been trying to avoid that since it requires local administrative permissions. Do you know if the Solo2 generally works with WebAuthn in Windows?

[d4g]

Seems linke solo2 is still a bit behind: https://github.com/solokeys/solo2/discussions/108

[NoMoreFood]

Any luck with non-resident keys on Solo2? Any other than the overall success/failure status you noted, any other general feedback based on the changes?

[queesamor]

I am just getting caught up with the last few months' progress now, so not yet for me.

------- Original Message ------- On Thursday, April 14th, 2022 at 05:49, Bryan Berns @.***> wrote:

@astelmachonak-nydig, @d4g, @kpostekk, @t3chn0m4g3, @ageis, @queesamor, @velosol, @RcTomcat1. Anyone happen to have a chance to test this version at all?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[velosol]

Tested using a YubiKey 5 NFC & 5ci - able to create resident & non-resident keys with touch and touch/PIN required (tested resident p256, p384, p521, & non-resident ed25519), was able to use these to login to a server; no other hardware PIV/CAPI/etc certs present during test.

Issues noted

• Missing a word under FIDO Keygen page -> User Name caption -> "... identifier that can be used ..."

• puttyimp.exe - doesn't seem to work from PuTTY

  • Running puttyimp --import-fido from an elevated command prompt does generate a PIN entry pop-up (classic Windows GUI styling, not modern Windows Hello) and then is able to restore keys.
    • With a YubiKey 5 NFC the number of keys found was one more than are listed on the token via libfido's fido2-token -L -r <deviceId> (fido2-token shows 3 resident keys 00, 01, 02; puttyimp says total keys imported: 4, could also be a resident key with a bad user verification extension in the credential protection policy e.g. bolded must at YubiKey). With a YubiKey 5ci the number of keys matched.
    • I have a webauthn.io resident key from other testing that PuTTY offers for use after puttyimp --import-fido; I assume this is intentional and the Application Name starting with ssh: is best practice/a de facto standard. Should PuTTY-CAC only import/offer keys starting ssh:?
      Ways it didn't work
  1. I can run it elevated (via GUI right-click & run as admin) outside of PuTTY-CAC but there's no success/failure indication
  2. Attempting to run it within PuTTY-CAC pops up the first dialog warning about "elevation will be required" then seems to immediately pop up the failure dialog (I really thought I got an elevation prompt at least once but I can't recreate it)
  3. After "Clearing Key Cache" I lost access to the resident key (as expected) and running puttyimp from GUI separately from PuTTY-CAC doesn't restore it
  4. Launching putty.exe as Admin and then clicking the "Import Keys..." button pops up a black console window for puttyimp but still doesn't seem to do anything (open for a few seconds then closed).
  • (Probably due to pre-release exes) The Windows Hello Security key setup page notes that putty.exe is an 'unverified app.'
  • (Known Issue) Windows security prompt pops under other windows but does flash in taskbar (Windows 21H2). Further pop ups (e.g. at key creation) pop up in the same location but do not have focus so you must click/alt+tab back into them to click 'OK' - seems reasonable behavior otherwise you could skip the notes on the new windows; is annoying for PIN entry.

General notes

• Semantic satiation and confusion with 'key' - there's 'key' the crytographic thing we're creating and there's the physical hardware key (token) on which the software key is stored.

  • I don't have a great suggestion here - you've used key only to mean the software key and 'FIDO token' for the hardware device so you thought about this but until I wrote this comment it didn't click that 'key' always meant software key - let's call that a PEBKAC issue :)
  • Possibly suggest that the application name should identify the token used as well as the key purpose? Testing with a few tokens it's easy to lose track of which has what resident key.
  • When do you see 'User Name' field in use? I can set it but haven't seen what I set show up again.
    Some things I noticed but are bordering on off-topic

• When you've selected a key and go to login if the key isn't on the server then PuTTY doesn't create a prompt for the PIN/touch entry - this seemed cool to me as the action to unlock/use the key (either touch or PIN & touch) doesn't happen upon the moment of use which isn't the same as the offer to the server.

• If you attempt to create a touch & PIN key and there is no PIN set on the device Windows Hello will do the PIN setup flow for the token.

• YubiKey Manager must be run as admin in order to set FIDO2 PIN or reset FIDO2; nothing to do with PuTTY-CAC but might save someone else some trouble.

  Issues related to p384 & p521 resident & non-resident keys (fairly confident these are not supported on this YubiKey and the issues are likely Windows Hello's)

• Attempting to create p384 or p521 keys with touch & PIN results in an infinite loop of being prompted for my security key PIN (can 'Cancel' out of the loop). Entering the wrong PIN is detected and the next prompt says "The PIN is incorrect. Try again."

• Attempting to create p384 or p521 keys with touch only and no PIN set on the key results in an error "Cannot read your security key" (as expected)

• Attempting to create p384 or p521 keys with touch only and a PIN set on the key results in the infinite prompting for my security key PIN again can 'Cancel' out.

Thank you for the feature!

[NoMoreFood]

@velosol Thanks for the testing and the great feedback. I will go over your items in detail after the day job today or tomorrow.

[NoMoreFood]

@velosol The only part I am having an issue with reproducing/understanding is the fact that PuTTYImp would not launch from the user interface with you. Are either the following true? PuTTYImp is launched from a path with over 256 characters? If you right click on PuTTYImp.exe and go to properties, do you see an option to 'Unblock' the executable? If so, does unblocking it change behavior?

Update: Ignore this message; I believe I found the issue.

[NoMoreFood]

@velosol

I have updated the binaries: https://github.com/NoMoreFood/putty-cac/tree/fido_dev_branch/binaries

Notable changes thus far:

• Attempted to address focus issues
• PuTTYImp should now be consistently executable from PuTTY
• Added suggested guidance on multiple tokens
• Set username field to static value; no clear benefit to allowing user to customize
• Correct noted typo

[velosol]

@NoMoreFood Lots of improvements in this build, nice work!

• I haven't had any focus issues in testing
• After clearing the key cahce; I can run PuTTYImp from PuTTY-CAC and it prompts for elevation and runs (and I see 'Total Keys Imported: 5' after entering my PIN), also it's being run from a path with 54 characters in it.
  • When I then click 'Set FIDO Key...' I get "No certificates available":
    Looking at HKCU\Software\SimonTatham\PuTTY\Fido\ It seems the PubKeyBlobs registry key isn't getting populated. If I create a new FIDO key in PuTTY I'll see it show up with an entry under PubKeyBlobs as well as under CredIdBlobs & UserVerification. I assume this isn't intentional as it would make 'Import Keys...' not very useful :smile:
  • Some last minute testing revealed that if I run PuTTYImp on its own and open PuTTY-CAC again I can select a resident FIDO key (and PubKeyBlobs is populated as expected).
  • I can't seem to import resident keys from a token with no PIN set (probably a YubiKey 5ci-etc limitation) - when I try to import keys from the token without a PIN set, I get prompted for a PIN (actually 'Password' - not sure if that's something you can change) by PuTTYImp and whether I enter nothing, a previous PIN, the default PIN, I see "Total Keys Imported: 0". If I set a PIN using Windows Hello settings then I'm able to import resident keys.
• After creating a new key, should it be set to the selected FIDO key (either by default or through a prompt)?
• I discovered that using the same Application Name will overwrite a previously generated key (e.g details below); perhaps a warning should appear if attempting to create a new key with the same name as an old key? It won't be foolproof as a cleared key cache without an 'Import Keys..' would mean PuTTY doesn't know about any resident keys and their application names among other scenarios.
  Some `fido2-token` runs showing what changes when re-creating a key with the same name

Lines trimmed for readability (e.g. full device ID removed, PIN entry prompt removed, extraneous keys removed):

>fido2-token -L -r "\\?\hid#vid_1050&pid_0407<deviceId>" # List resident keys on token
02: 4wYQ6KFiEVlg/h7CI+ZSnJ9LboAgDcteXDIcivHisb8= ssh:

FORMAT is: index: rp_id_hash fido_credman_rp_id(i.e. the relyping party id) per libfido2

>fido2-token -L -r -k "ssh:" "\\?\hid#vid_1050&pid_0407<deviceId>" # List credentials for relying party "ssh:"
00: V089XBD9KjFVVkheNEjbIw== PuTTY FIDO User UAB1AFQAVABZACAARgBJAEQATwAgAFUAcwBlAHIA eddsa uvreq

FORMAT is: index: id credential_display_name user_id key_type key_protection per libfido2

Create new touch-only resident key named "ssh:" in PuTTY's FIDO interface

>fido2-token -L -r "\\?\hid#vid_1050&pid_0407<deviceId>"
02: 4wYQ6KFiEVlg/h7CI+ZSnJ9LboAgDcteXDIcivHisb8= ssh:

Resident key for "ssh:" is still there and the relying party id hash is the same

>fido2-token -L -r -k "ssh:" "\\?\hid#vid_1050&pid_0407<deviceId>"
00: /qhWfZR8wnEfdoJbj0fHPw== PuTTY FIDO User UAB1AFQAVABZACAARgBJAEQATwAgAFUAcwBlAHIA eddsa uvopt

Resident key id is different and the user verification field has been updated Create new resident key named "ssh:" in PuTTY's FIDO interface

>fido2-token -L -r -k "ssh:" "\\?\hid#vid_1050&pid_0407<deviceId>"
00: aND4WRof7nfPKufK5mSO4w== PuTTY FIDO User UAB1AFQAVABZACAARgBJAEQATwAgAFUAcwBlAHIA eddsa uvopt

Another new id.

Working through this round of testing I did wonder about key management - is it PuTTY's place to provide a way to delete resident keys (either from the token if that's even possible or just removing some keys from the listing under 'Set FIDO Key...')? If so, where would that be? Obviously regedit is available but I'm wondering if there's a place for some key management in the GUI.

Final thought is should FIDO key generation be anywhere else? puttygen or pageant come to mind - the former as it's where keys are generated more generally and the latter as it's sometimes used standalone as an agent for other programs. Consider these open ended questions as the late night thoughts they are; either better tracked in other issues or not at all.

[NoMoreFood]

@velosol

• I found the PubKeyBlobs population issue (coding copy/paste issue on my end). They way it's run via the GUI is unique because I tried to take into account that the user needed to elevate might not be the same account as the one that is SSHing so I pass in the user SID to PuTTYImp and it binds to the registry under HKU\SID to create the subkeys. I'll bucket up some other changes before I push a new set of binaries with the fix.
• I like the idea of prompting to set the key as default after adding so I'll add that in.
• In terms of where key generation should be done; the only reason I put it in PuTTY is that the UI creation in there is pretty flexible. It probably belongs in puttygen so I'm considering a move there, I just have to see how painful it would be and whether it would make things less convenient. In either case, I agree that some sort of way to work it in Pageant would be desirable as well.
• Dealing with multiple credentials for same-named keys is tough, and I'm still thinking about the best way to come through it. I really don't want to try to try to track them (and creating some weird sub-structure in my registry key area).
• Yubico sent me a YubiKey 5ci that'll be here on Thursday so I'll see if I can reproduce the behavior your mention.
• It probably wouldn't be too bad to add on a key deletion option so I'll consider that.

Thanks for your continued testing. I'll let you know when there's another revision worth your time.

[velosol]

I knew I was forgetting something last night - my last thought on key management is whether it's possible to utilize a resident key on a machine where you didn't create it and don't have admin. Especially useful moving a token between machines in a locked down environment.

I assume you'd have to know the 'Application Name' but I don't know if Windows Hello allows a query with just the relying party/application name combo - it seems like it should be possible as long as the key was generated by PuTTY in the first place (at least as I read YubiKey's docs). If OpenSSH generates keys with predictable names then it's feasible to support those as well.

Thank you for all your work on the PuTTY-CAC family!

[NoMoreFood]

Updated version available: https://github.com/NoMoreFood/putty-cac/tree/fido_dev_branch/binaries

• Added prompt post-key generation to set key.
• Changed PuTTYImp to only request PIN if indicated it was necessary by the token (usually is in most cases).
• Added option to delete key in KeyGen area (requires elevation).
• Force focus to Pageant before requesting a signature to aid with focus changes.

@velosol In terms of registering an existing key, you are correct about only needing the application name for FIDO, in general. Unfortunately, in order for us to know to send the public key offer to the remote server we also need to import that from the token. Luckily, many business environments use roaming profiles and that will help keep the registry keys in place. I still plan on incorporating a few of your other recommendations over the next week.

I'm still waiting to get my renewed code signing certificate from Certum. I'm hoping receipt of that should line up when upstream PuTTY 0.77 finally release which will include these FIDO updates.

[raphj92]

@NoMoreFood

I tried putty-cac with my SafeNet IDPrime 3940 from Thales which works well with Windows Hello. It is a smartcard that support PKI and FIDO2 through contact and contactless access (ISO 14443). While trying to create the key it asked me to touch the device like you would with a Yubikey. But as it is a smartcard there is no "touch" interface and it was not able to complete the creation task. It tried both touch and touch+PIN options.

Let me know if there is anything I can do to provide debug data.

Thanks a lot for this great tool !

[NoMoreFood]

@raphj92 Interesting. Are you able to use it on FIDO2 / WebAuthn on websites without it needing to do the touch option (e.g. on https://webauthn.io/)? As far as I know, the WebAuthn library does not give me any way to disable the touch component.

[queesamor]

As far as I know, Google's Titan keys don't have a touch option like Yubikeys, and I know that phone-based FIDO2 keys don't... 🤔

-------- Original Message -------- On May 16, 2022, 16:28, Bryan Berns < @.***> wrote:

@.***raphj92 Interesting. Are you able to use it on FIDO2 / WebAuthn on websites without it needing to do the touch option (e.g. on https://webauthn.io/)? As far as I know, the WebAuthn library does not give me any way to disable the touch component.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[NoMoreFood]

@queesamor A quick glance at the Titan Keys makes it look like they might support it. The main question I have though (for somebody who owns one of these) is whether the keys work on Windows for WebAuthn against websites. If they do, then I'm just missing something in the WebAuthn API that should allow it to operate in "no touch" mode.

[raphj92]

@NoMoreFood I was able to register and log in on the webauthn.io web site. When it asked to tap on the security key, I removed the card from the reader and reinserted it, and it worked. So I tried the same action on putty-cac when trying to create the key and got a message saying "This security key can't be used. Try another one". Could it be because there is already a key on the card ? I tried the import keys action but it does not import any key and doesn't seems to care if the card is inserted or if the PIN code is correct or not...

[NoMoreFood]

@raphj92 Interesting. When you create a key in PuTTY CAC, are you selecting non-resident key? Some tokens don't support resident keys. I'll reach out to Thales and see if I can get one of those cards sent to me.

[raphj92]

@NoMoreFood

I tried both with the same result...

[NoMoreFood]

@raphj92 Thales sent me an SafeNet IDPrime 3940 and it looks like I can reproduce the behavior you describe. I'll be looking into it over the next few days. Thanks for your testing thus far.

[NoMoreFood]

@raphj92 Actually may have already found the issue. Try the ecdsa-sha2-nistp256 algorithm and see if the behavior is any different. It appears sites like webauth.io default to this algorithm so I'll consider making this the default.

[NoMoreFood]

PuTTY 0.77 finally released. I merged those changes and created a pre-release. If anyone could test/retest, I would appreciate it.

[NoMoreFood]

After getting some feedback through other avenues, I removed the pre-release status. Please open new issues for any future questions/issues/requests.

[OperativeThunny]

with passkeys being prevalent now like windows hello was, it is now easily possible to have multiple different FIDO2 authenticators available. How does one select which one to prompt with puttyimp.exe ? I have multiple different authenticators, a YubiKey, a Thales safenet 3940, and this fantastic authenticator because it is cheaper than the others on amazon a Cryptnox FIDO2 smart cardl I try importing keys and it says 0 keys imported from the smart cards but I know there are keys because I created one with the endsa 256 also in the putty-cac interface and verified it was there then I cleared the putty cache to simulate going to a new pc, and then tried importing using puttyimp.exe from an admin terminal, and using the puttyimp button, and it prompts for a pin, but does not interrogate the smart card and just says 0 keys imported. I am assuming / guessing this is because it is only defaulting to the first fido provider it can find or something (I don't know the basics of the clap protocol so idk) and so if you have like 3 different fido devices plugged in it doesn't know what to do ??? idk but yeah annoying.