Enable FIDO support

[bagajjal]

OpenSSH V8.6 (released on 5/27/2021) doesn't have FIDO support.
This issue is used for tracking.

[needs-coffee]

thanks for releasing the 8.6 package. Just to clarify when you say that FIDO support is not availible in window 8.6 release you are referring to 'ecdsa-sk' and 'ed25519-sk' key types that were released in openssh 8.2?
if so, any particular reason this is not supported?

[bagajjal]

Yes. It's not straight forward to enable on windows. It involves more work. I want to get the V8.6 out and later work on FIDO.

[tavrez]

Thanks for the release, here is the information I can provide about FIDO:

1. First way to enable it is, to use the built-in internal implementation they did in OpenSSH itself, it requires libcbor and libfido2 and administrator privilages in windows 1903 and higher.
2. Other way is to use Windows Hello APIs, just like what I did in my dll module, but instead of being module, it can replace the internal implementation. However, Windows Hello lack 1 API so it cannot fully do all the stuffs needed in OpenSSH.
   • 4 functions should be implemented: version return, create new key, sign a challenge with existing key, return list of resident keys. the latter one is not available in Windows Hello, maybe guys at https://github.com/microsoft/webauthn @akshayku could help about it.

The other thing is how you want to implement ssh-sk-helper.exe, I'm not sure if you need to change it at all or it's good in the way it is. But just to give brief info for tracking here:

• When you want to do anything with FIDO keys, OpenSSH create a fork and launch this app, this app then decide which implementation it should use(internal or a dll) then use it to sign and answer back. It use environment variables when launched from ssh-keygen and ssh-add and use ssh config file when it launched from ssh or sshd.

[bagajjal]

Thanks @tavrez.
We are in sync with WebAuthn team (@akshayku). They are in talks with Yubico to implement missing pieces.

To be transparent, currently this work is in our backlog. Once WebAuthn team comes back after Yubico has full implementation, we will prioritize this work.

[tavrez]

As far as I know the implementation exists in libfido2 (OpenSSH is actually using it), it need to be ported into Windows Hello webauthn.

Anyway I'll help on each part I can when it became ready.

[NYCJames]

Hi @bagajjal,

I was wondering if you could provide an update on the status of FIDO support.

[bagajjal]

@NYCJames , We have this in our backlog. At this point it's not prioritized.

[olljanat]

Btw. It looks to be that someone has already implemented FIDO support on https://github.com/tavrez/openssh-sk-winhello
I just left comment to tavrez/openssh-sk-winhello#11 about switching to compatible license.

[gbloice]

Btw. It looks to be that someone has already implemented FIDO support on https://github.com/tavrez/openssh-sk-winhello
I just left comment to tavrez/openssh-sk-winhello#11 about switching to compatible license.

See the comments by @tavrez above.

[d4g]

I really don't understand, how this is not prioritized. You say that this is OpenSSH 8.6 but it's actually only a part of it, as a major functionality that was release over a year ago is still not working on windows at all. Just have a look at #1557 .
This really should be a priority, as it will add important security features. Please reconsider of putting this on the backlog instead of focusing on implementing it.

[martelletto]

libfido2 1.8.0 (released 2021-07-22) introduced support for Windows's native webauthn API. To support ssh-sk, a few modifications are required in https://github.com/PowerShell/openssh-portable; these can be found at PowerShell/openssh-portable@latestw_all...martelletto:fido2. Step-by-step build and test instructions are available in https://gist.github.com/martelletto/6a7cf806c6433ac9ce71d66afb94d70e.

[nkrepo]

Thanks @tavrez.
We are in sync with WebAuthn team (@akshayku). They are in talks with Yubico to implement missing pieces.

To be transparent, currently this work is in our backlog. Once WebAuthn team comes back after Yubico has full implementation, we will prioritize this work.

@bagajjal Is there any eta for the FIDO2 support ?

[d4g]

@bagajjal is there any update?
I would also like to reclassify this issue. This is not an enhancement, it's a missing feature, that the original OpenSSH supports.

[MrRinkana]

FIDO2 support is being worked on in PowerShell/openssh-portable#541

(@d4g, @nkrepo)

[bagajjal]

For those of you interested, please find the private SSH binaries with FIDO support here. This currently doesn't support registering the FIDO private keys with ssh-agent.exe. We are currently working on this.

Usage,

1 Create a ecdsa-sk credential on a security key:

> ssh-keygen -t ecdsa-sk

2 Setup the key based authentication using the generated ecdsa-sk.pub key. Follow instructions here

3 ssh user@ip -i <path_to_ecdsa-sk-private-key-file>

4 You are prompted to confirm the user presence by touching your security key.

Please note, the security device (Yubico) must be physically connected to the machine running ssh.exe. It doesn't work over the RDP / Hyperv VMs. This is a limitation on windows OS.

Please let us know if you encounter any issues

[Trolldemorted]

Please note, the security device (Yubico) must be physically connected to the machine running ssh.exe. It doesn't work over the RDP / Hyperv VMs. This is a limitation on windows OS.

Will this limitation be lifted in the future? The pandemic has increased the usage of rdp a lot, you know :|

[zviratko]

RDP is capable of formarding Smartcards, but I don't think it forwards Smartcard readers. Most FIDO tokens will show as a CCID reader, not as a smartcard (because that's not what they are), so that's not an easily solvable problem I think. Microsoft would have to do some sort of universal Hello forwaring over RDP.

[bagajjal]

@Trolldemorted , @zviratko ,
Microsoft webauthN team is working on a feature to support the remoting scenarios.
Adding @akshayku from Microsoft webauthN team for any follow up questions.

[akshayku]

@Trolldemorted / @zviratko

We are working on it. Actually you should be able to test it now in Windows insiders builds. Note that both client and server needs to be on insiders build.

[Trolldemorted]

We are working on it. Actually you should be able to test it now in Windows insiders builds. Note that both client and server needs to be on insiders build.

You mean the windows hello forwarding? That'd be super useful, what is the minimum windows build version for that? Do you expect this feature to arrive in older windows builds? You know, corporate machines are often on LTSC channels, it takes literally years until bugfixes and features reach us :)

[zviratko]

@Trolldemorted / @zviratko

We are working on it. Actually you should be able to test it now in Windows insiders builds. Note that both client and server needs to be on insiders build.

Cool!
Any chance of seeing it in the macOS RDP client?

[Roang-zero1]

For those of you interested, please find the private SSH binaries with FIDO support here. This currently doesn't support registering the FIDO private keys with ssh-agent.exe. We are currently working on this.

Usage,

1 Create a ecdsa-sk credential on a security key:

> ssh-keygen -t ecdsa-sk

2 Setup the key based authentication using the generated ecdsa-sk.pub key. Follow instructions here

3 ssh user@ip -i <path_to_ecdsa-sk-private-key-file>

4 You are prompted to confirm the user presence by touching your security key.

Please note, the security device (Yubico) must be physically connected to the machine running ssh.exe. It doesn't work over the RDP / Hyperv VMs. This is a limitation on windows OS.

Please let us know if you encounter any issues

@bagajjal I've tried to use the provided binaries today but I received the following error:

> .\ssh-keygen.exe -t ecdsa-sk -a 500 -b 521
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
Provider "C:\\Users\\<username>\\lib\\winhello.dll" dlopen failed: The specified module could not be found.
Key enrollment failed: invalid format

I've had the winhello.dll from https://github.com/tavrez/openssh-sk-winhello/releases/tag/v2.0.0 installed there, but neither removing nor redownloading the dll had any effect on the problem.
Are there any additional steps necessary in oder to use these binaries?

[Roang-zero1]

Documenting for anyone who had set up https://github.com/tavrez/openssh-sk-winhello before:
You need to unset the SSH_SK_PROVIDER environment variable before you can use the experimental binaries.

[bagajjal]

PowerShell/openssh-portable#541

[JunielKatarn]

@bagajjal will this be included in this half year's Windows 11 update?

[bagajjal]

@JunielKatarn - We are trying our best to include V8.9 (with has FIDO2 support) in next Windows release. At the moment, I can't promise as windows timelines are very strict and they wouldn't allow large changes late in the release cycle.

[JunielKatarn]

@bagajjal Thanks.

If there is any testing / validation that I could do to help, let me know. I am interested in this feature on Windows (MS FTE: jurocha).

[Neurrone]

@bagajjal does this support registering the FIDO private keys with ssh-agent.exe? Would I also be able to use it from WSL2?

[bagajjal]

@Neurrone - V8.9 supports registering the FIDO private keys with ssh-agent.exe. I never tried to use if from WSL2.

[Neurrone]

I encountered the following error while trying to regenerate the key from the YubiKey:

>ssh-add -K
Cannot download keys without provider

After I got the stub files on the machine, I tried adding the private key to the ssh-agent and tried using it to SSH into a machine. Doing so fails with the following error:

sign_and_send_pubkey: signing failed for ED25519-SK "c:/Users/dickson/.ssh/id_ed25519_sk" from agent: agent refused operation

Removing that key from the agent fixes this error, it prompts me to touch my device as expected.

[bagajjal]

@Neurrone - Win32-openssh uses the internal provider, that's shipped with openssh. Are you sure, you are using win32-openssh ssh-add V8.9? code here.

If you installed v8.9 using MSI then there is a known issue. If not, then please check event viewer to find out the ssh-agent error message.

Also please open a new issue as this issue is for different purpose and it's closed.

[bagajjal]

@Neurrone - sorry, the code is disabled for windows. I will look into it.
For now, you can download the resident keys with "ssh-keygen.exe -K".

[martelletto]

Please note that ssh-keygen -K requires direct communication with the FIDO token, so it needs to be issued from an elevated prompt.

[bagajjal]

@Neurrone - fyi, I created #1915 for tracking.

Please don't reply to this issue. If you encounter any issue, request to create a new issue so it's addressed properly.

[bagajjal]

For FIDO usage, please refer to https://github.com/PowerShell/Win32-OpenSSH/wiki/FIDO---U2F-usage

[abairit]

Hello bagajjal, I'm using Yubi Key and followed the instructions in the wiki to make OpenSSH 8.9 working with FIDO.
My problem is that I have to call every ssh command in a admin prompt. Even after generating the key and adding it to ssh agent.
I use the key to authorize in gitlab and every git command needed to be execute from elevated prompt. Otherwise the Yubi Key is not found.

I also tried to use https://github.com/tavrez/openssh-sk-winhello, but the latest Version has no support for Open SSH 8.9.
Is it right that we need admin permissions to use Open SSH with Fido and YubiKey? Or is there a working solution to use Open SSH 8.9 with FIDO without admin permissions?

Best regards

[NoMoreFood]

@abairit Usually only certain interactions with the Yubikey require administrative permissions; I'm not sure why you seem to be getting it for everything. As an experiment, you could try downloading my PuTTYImp program (https://github.com/NoMoreFood/putty-cac/blob/master/binaries/x64/puttyimp.exe) and then, under an administrative command prompt, execute: puttyimp --grant-fido. I'd be curious if that changes the behavior for you.

[abairit]

Hi,
i executed puttyimp --grad-fido from an adminstrative cmd. Then tried git fetch from a shell without admin privileges.
Still getting the error, that the yubi key was not found:
sign_and_send_pubkey: signing failed for ECDSA-SK "/c/Users/myuser/.ssh/id_ecdsa_sk": device not found

When I run git fetch from an administrative shell, it works without the error message. I have to touch the yubi key to authorize and everything is fine. But without administrative shell, the yubi key is not found.

[NoMoreFood]

@abairit Darn, thanks for trying.

[abairit]

any other ideas to get the yubi key working with openssh 8.9 and FIDO without a administrative shell?
It would be okay to generate the key once with admin privileges. But not on every interaction (when using git pull/push e.g)