ssh-sk-helper failing sshsk_sign with code -2 (requested feature not supported) #1
Comments
|
Thanks for reporting, could you tell me:
|
|
Thanks for responding so quickly.
|
|
Removing SecurityKeyProvider should be enough, remember to run git bash as
administrator.
Also could you tell me if you are running Windows in VM or not.
Seems like the problem is with the webauthn.dll not returning success
message after initiation, you can also test any FIDO process inside any
browsers and see if they are using win hello or falling back to their own
implementation
…On Thu, May 28, 2020 at 12:19 AM Rob Deker ***@***.***> wrote:
Thanks for responding so quickly.
1. I am using the binaries from your github release
2. Can you clarify exactly what you'd like me to log? I'm not sure if
you mean simply removing the SecurityKeyProvider configuration, reverting
to the ssh-sk-helper provided by Git for Windows, or something else.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACFM2DKLM6U5TLMX2HYYK6TRTVVELANCNFSM4NMHBL3A>
.
|
|
I've tried in a VirtualBox Win10 virtual, and on Win10 running natively. As an additional note, the id_ecdsa_sk was generated on a Linux box and copied to Windows, but I've verified that the key is identical and didn't get mangled in copying. etc. Using the same key file and same YubiKey device works fine from a linux host (Ubuntu 20.04). Using Win10 running natively, running Git bash as administrator, with the SecurityKeyProvider disabled in the ssh config, and the original ssh-sk-helper.exe (just in case), I get the following (note that there is a pause of several seconds after "find_device: found key"): For completeness, on the same Windows host, with the SecurityKeyProvider enabled, and using your modified ssh-sk-helper.exe, I get the following with no real delay noticeable: Any thoughts or additional help are greatly appreciated. |
|
Your first run shows that ssh found your key, but when it's tried to communicate with it, it got no answer, something must be wrong with the key or it's softwares(driver, configuration,...) Could you please tell me:
I'm working on a new release for OpenSSH 8.3 which doesn't need modified ssh-sk-helper, I'll add more debug information to module to see what is wrong with your configs |
|
I just remembered another thing: |
|
Reza,
|
|
I seem to be having the same or a similar issue. With the current version (1.0 RC), I get an error when I try to use or generate a key: I'm on 20H1, I can use FIDO from a browser (I've tried Firefox, Chrome, and Edge) without any issue, and I did not use the no-touch-required option when trying to generate a key. I've also tried two different FIDO2 keys with the same result. |
|
@rdeker firefox has two implementation for accessing fido keys, can you show me the screenshot of your browser when web application ask for the key? Or just confirm it's same as the one I posted in README file. |
|
@jschwina Can you also post screenshot of your browser when it's asking for key? |
|
Sure, it's the Windows Hello implementation: And yes, the internal implementation of OpenSSH for FIDO keys works fine with administrator privileges. |
|
No idea if useful but Yubico has a Python implementation of interacting with the U2F key in Windows: https://github.com/Yubico/python-fido2/blob/master/fido2/client.py#L647-L752 https://github.com/Yubico/python-fido2 Under Windows 10 (1903 or later) access to FIDO devices is restricted and requires running as Administrator. This library can still be used when running as non-administrator, via the fido.client.WindowsClient class. An example of this is included in the file examples/credential.py. |
|
It is not so different with what I did, my code is inspired by Google Chrome and Firefox source code. When this module is not working and browsers are working at the same time, there most be some settings preventing this module from accessing WinHello platform(maybe because of being an unsigned app) |
|
@tavrez Off-topic: Since you know way much more about this than me. Do you know if this could be done in Pageant for something like PuTTY? Can the ssh-agent do all the work and the ssh client not need to be modified? I'm guessing no, but was hopeful it might be a yes and then could create an ssh agent that could work with PuTTY, or in my case MobaXterm. Thanks! |
Some part of working with FIDO keys implemented inside ssh client and server, they need to know how to handle new key types(ecdsa-sk and ed25519-sk). Signing and verification process of these two keys are different with normal ecdsa and ed25519 so it can't be done using agent alone. |
Hi, I'm using your openssh-sk-winhello binaries on Win10 version 1909, build 18363.778 with Git for Windows version 2.62.2-64-bit and a YubiKey 5 NFC. System is running in a Virtualbox VM (though I have also tried with a native Windows install on another machine). When I originally set things up, authentication to a Linux host (Ubuntu 20.04, OpenSSH 8.2p1, also a VM) was functioning, but having come back to it a bit later to document for a client, auth is now failing.
Using the same YubiKey and ecdsa_sk key from a Linux host works perfectly.
Here is the output of "ssh -v" on the Windows host:
Any advice or assistance would be greatly appreciated. Please let me know what other debug info would be useful.
The text was updated successfully, but these errors were encountered: