tavrez / openssh-sk-winhello

A helper for OpenSSH to interact with FIDO2 and U2F security keys through native Windows Hello API

Hi there 👋

openssh-sk-winhello's Issues

Support for platform authenticator (TPM)?

Hi,
I'm working on a PoC with FIDO tokens for SSH keys and I would like to (also) use the built-in Windows Hello FIDO token. However the only option I am given is to insert a security key. Is this a known limitation?

If I had to guess

1. maybe everything needs to be signed correctly to get access to the platform authenticator
   or
2. might be related to your mention of WebAuthNIsUserVerifyingPlatformAuthenticatorAvailable in ChangeLog
   or
   something completely different :-)

Thanks

P.S. are you aware of a way to actually check the attestation data? Looks like OpenSSH does it a bit different from regular WebauthN workflow, in particular there is no clientData in there...

windows.h

Hello! I want to install your project on wsl2, but when you start make, I get a message that fatal error: windows.h: No such file or directory if other errors appear. Please tell me, maybe something needs to be established before making such mistakes?

Error during keygen

Goodday when i try to generate a key it gives the following error. but it does make the keys however i have the feeling those keys are not bound to my U2F key here is the information about the error and the command i used

Error: WinHello API Error: Version=2, Is user available=0, user=0

Command: ssh-keygen -t ecdsa-sk -w /etc/winhello.dll -O user=Lars

Note: user Lars exist on the windows system

Could not add identity "id_ecdsa_sk": agent refused operation

Hello and thanks for the amazing project!

I'm encountering a few issues trying to setup password-less authentication with your tool on one of my servers.
In short, I'm doing the following: https://github.com/mooltipass/minible/blob/gh-pages/fido2_openssh_from_windows.md
However, ssh-add -S winhello.dll id_ecdsa_sk fails while ssh-add id_ecdsa_sk succeeds ....

Not working, Windows 11

I'm not sure what I'm doing wrong here, I've added the path to my ssh config and added the environment variable and it still doesn't seem to be working:

C:\Windows\System32>ssh-keygen -t  ecdsa-sk
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
Key enrollment failed: unknown or unsupported key type

C:\Windows\System32>echo %SSH_SK_PROVIDER%
C:\Users\desu\bin\winhello.dll

C:\Windows\System32>type C:\Users\desu\.ssh\config
PKCS11Provider "C:\Program Files\Yubico\Yubico PIV Tool\bin\libykcs11.dll"
SecurityKeyProvider "C:\Users\desu\bin\winhello.dll"
C:\Windows\System32>

"winhello.dll is not an OpenSSH FIDO library" says WSL

While I also have been unable to get this working in Windows's side, we can refer to WSL.md which sends us commands for this to work, which I have then entered, as below results:
> SSH_SK_HELPER=/mnt/c/Program\ Files/Git/usr/lib/ssh/ssh-sk-helper.exe SSH_SK_PROVIDER=/mnt/f/winhello.dll ssh-key gen -t ed25519-sk -O resident Generating public/private ed25519-sk key pair. You may need to touch your authenticator to authorize key generation. lib_contains_symbol: open /mnt/f/winhello.dll: No such file or directory provider /mnt/f/winhello.dll is not an OpenSSH FIDO library Key enrollment failed: invalid format
It matters not whether files are in the same or different directory either :)
Without the files referenced in #12, namely the msys dlls, the command provides us with this:
Generating public/private ed25519-sk key pair. You may need to touch your authenticator to authorize key generation. client_converse: receive: unexpected internal error reap_helper: helper exited with non-zero exit status Key enrollment failed: unexpected internal error
Unsure how to get this working, since it seems to register on Windows as an OpenSSH FIDO library, namely these results:
> ssh-keygen -w F:\winhello.dll -t ed25519-sk -O resident Generating public/private ed25519-sk key pair. You may need to touch your authenticator to authorize key generation. Enter PIN for authenticator: Key enrollment failed: unknown or unsupported key type
But still doesn't work at all. Without resident flag, all it does is just immediately hit the "Key enrollment failed" line without even waiting for PIN on the authenticator. Unsure the problem here. I have putty installed if that's an issue, but I'm not sure if pageant is interfering given I haven't even set it up for smartcard auth? I have OpenPGP keys on the card already but since that's OpenPGP and these are FIDO so they shouldn't interfere right?

Interoperability with OpenSSh 8.9

OpenSSH 8.9 for Windows has just been released, and it supports fido2 keys.

Is there any way that I could use winhello from WSL2 to take advantage of that,? As an alternative to using the ssh in git for windows.

Compiled for cygwin - client_converse: receive: unexpected internal error

Hello,

first of all thanks for your awesome work!

I am using your released binaries v2.0.0 with gitforwindows with OpenSSH_8.4p1 and it worked like a charm.

Now I am trying to make it running with MobaXTerm (cygwin)

What i have done so far:

• cloned repo on tag v2.0.0
• ./setup-x86.exe -root <path> -q -P gcc-core -P gcc-g++ -P libssl-deve -P automake -P autoconf -P libtool
• autoconf --install
• ./configure
• make
• Copied src/.libs/winhello.dll

Executed
SSH_SK_PROVIDER=<path>/winhello.dll ssh-keygen -vvv -t ecdsa-sk -f ./fido

After a warning (already read in other issues, that this should be no problem):
WinHello API Error: Is User available=0, User=0

Then the following error is returned:

client_converse: receive: unexpected internal error
debug3: reap_helper: pid=7640
reap_helper: helper exited abnormally
Key enrollment failed: unexpected internal error

Any ideas what could be the problem?

Query regarding non-admin functionality

Hello,

First and foremost - thank you for releasing this interesting project to the open source community.

I understand through reading your project that you can interact with the FIDO/U2F keys without Administrator privileges by using the Windows Hello API.

Can you confirm for me whether you can use this project entirely without Administrator rights? e.g. not running Git for Windows as Administrator.

Can you also let me know if there is any implementation option using this using WSL2? I understand Git for Windows uses POSIX which is being deprecated.

My goal is to be able to enable FIDO/U2F (or PIV Smart Card) authentication from Windows 10 Enterprise hosts to Linux systems. Unfortunately the OpenSSH implementation in Powershell is woefully out of date.

OpenSSH 8.9 breaks version 2.0.0

Looks like OpenSSH 8.9 has updated the required version for the FIDO library, which breaks version 2.0.0:

$ SSH_SK_PROVIDER=winhello.dll ssh-keygen -t  ecdsa-sk
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
Provider "winhello.dll" implements unsupported version 0x00070000 (supported: 0x00090000)
Key enrollment failed: invalid format

Unable to generate keys using YubiKey

Hi,

I'm on windows 10 21h1. I've updated to the latest version of OpenSSh for windows (8.6b1) and have also edited my c://.ssh/config to add these lines:

Host *
    SecurityKeyProvider "C:\Program Files\OpenSSH-Win64\winhello.dll"

However, that version of OpenSSH does not yet have fido2 support, hence why I'm trying this middleware, see PowerShell/Win32-OpenSSH#1804.

I'm finding that no matter which commands I use to generate a new key, it fails with an unrecognized algorithm.

> ssh-keygen -t ed25519-sk -O resident -f c:/users/dickson/.ssh/id_mykey_sk
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter PIN for authenticator:
Key enrollment failed: unknown or unsupported key type

Likewise, I get the same result when using ssh-keygen -w "C:\Program Files\OpenSSH-Win64\winhello.dll" -t ecdsa-sk both with and without specifying the full path of the dll.

ssh-sk-helper failing sshsk_sign with code -2 (requested feature not supported)

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:

$ SSH_SK_HELPER=/usr/lib/ssh/ssh-sk-helper.exe ssh -vv -i ~/.ssh/id_ecdsa_sk [email protected]
OpenSSH_8.2p1, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /c/Users/Deker/.ssh/config
debug1: /c/Users/Deker/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug2: resolve_canonicalize: hostname 10.10.1.222 is address
debug2: ssh_connect_direct
debug1: Connecting to 10.10.1.222 [10.10.1.222] port 22.
debug1: Connection established.
debug1: identity file /c/Users/Deker/.ssh/id_ecdsa_sk type -1
debug1: identity file /c/Users/Deker/.ssh/id_ecdsa_sk-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 Ubuntu-4
debug1: match: OpenSSH_8.2p1 Ubuntu-4 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.10.1.222:22 as 'deker'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ssh-ed25519,[email protected],rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,3des-cbc,aes256-cbc,aes192-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,3des-cbc,aes256-cbc,aes192-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:BbeOXU9GQubTOCVJmzlQEuTt0OIhh8IDcJGzT47NQLY
debug1: Host '10.10.1.222' is known and matches the ECDSA host key.
debug1: Found key in /c/Users/Deker/.ssh/known_hosts:2
debug2: set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /c/Users/Deker/.ssh/id_ecdsa_sk  explicit
debug2: pubkey_prepare: done
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,[email protected],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected]>
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /c/Users/Deker/.ssh/id_ecdsa_sk
Enter passphrase for key '/c/Users/Deker/.ssh/id_ecdsa_sk':
debug1: start_helper: starting /usr/lib/ssh/ssh-sk-helper.exe
debug1: ssh-sk-helper: ready to sign with key ECDSA-SK, provider winhello.dll: msg len 247, compat 0x4000000
debug1: sshsk_sign: provider "winhello.dll", key ECDSA-SK, flags 0x01
debug1: sshsk_open: provider winhello.dll implements version 0x001c0000
debug1: sshsk_sign: sk_sign failed with code -2
debug1: ssh-sk-helper: Signing failed: requested feature not supported
debug1: ssh-sk-helper: reply len 8
debug1: client_converse: helper returned error -59
debug1: identity_sign: sshkey_sign: requested feature not supported
sign_and_send_pubkey: signing failed for ECDSA-SK "/c/Users/Deker/.ssh/id_ecdsa_sk": requested feature not supported
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
[email protected]'s password:

Any advice or assistance would be greatly appreciated. Please let me know what other debug info would be useful.

user_id behavior mismatch with OpenSSH

openssh-sk-winhello/src/winhello.c

Lines 273 to 279 in 2cde676

	wchar_t lUserId[32] = L"SSH User";
	if (strcmp(user_id, "") && (convert_byte_string(user_id, strlen(user_id) + 1, lUserId) <= 0))
	{
	skdebug(__func__, "convert_string user_id failed");
	goto out;
	}
	WEBAUTHN_USER_ENTITY_INFORMATION userInfo = {WEBAUTHN_USER_ENTITY_INFORMATION_CURRENT_VERSION, strlen(user_id) + 1, user_id, lUserId, NULL, lUserId};

This doesn't match OpenSSH but not for the reasons mentioned in the README.

OpenSSH always uses 32 bytes for user_id. I.e., WEBAUTHN_USER_ENTITY_INFORMATION.cbId should always be 32 and not be based on strlen. If the user didn't specify anything, user_id will contain 32 zero bytes.

https://github.com/openssh/openssh-portable/blob/V_8_9_P1/sk-usbhid.c#L839

C:/cygwin/usr/sbin/ssh-sk-helper.exe errors out if C:\cygwin\bin is not in PATH

Thank you for this very useful helper program. I have noticed a potential issue when built for cygwin. I followed https://github.com/tavrez/openssh-sk-winhello#install and added SecurityKeyProvider /usr/lib/winhello.dll to my ~/.ssh/config. Everything works fine when ssh is run inside a proper Cygwin shell with C:\cygwin\bin in PATH, but does not work (ssh-sk-helper.exe errors out as seen below) when ssh.exe is run outside a Cygwin shell, e.g. a C:\cygwin\bin\ssh.exe shortcut or from vscode.

C:\Users\at>C:\cygwin\bin\ldd /usr/lib/winhello.dll
        ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff808c10000)
        KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ff808710000)
        KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ff8065c0000)
        winhello.dll => /usr/lib/winhello.dll (0x4580c0000)
        user32.dll => /cygdrive/c/Windows/System32/user32.dll (0x7ff8087d0000)
        win32u.dll => /cygdrive/c/Windows/System32/win32u.dll (0x7ff806540000)
        gdi32.dll => /cygdrive/c/Windows/System32/gdi32.dll (0x7ff807e30000)
        gdi32full.dll => /cygdrive/c/Windows/System32/gdi32full.dll (0x7ff8069c0000)
        msvcp_win.dll => /cygdrive/c/Windows/System32/msvcp_win.dll (0x7ff806be0000)
        ucrtbase.dll => /cygdrive/c/Windows/System32/ucrtbase.dll (0x7ff806890000)

C:\Users\at>c:\cygwin\bin\ssh at@ra
Confirm user presence for key ED25519-SK SHA256:[...]
ssh_msg_recv: read header: Connection reset by peer
client_converse: receive: unexpected internal error
C:/cygwin/usr/sbin/ssh-sk-helper.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory
reap_helper: helper exited with non-zero exit status
sign_and_send_pubkey: signing failed for ED25519-SK "/cygdrive/c/home/.ssh/id_ed25519-sk": unexpected internal error
at@[...]: Permission denied (publickey).

C:\Users\at>set PATH=C:\cygwin\bin;%PATH%

C:\Users\at>C:\cygwin\bin\ldd /usr/lib/winhello.dll
        ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff808c10000)
        KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ff808710000)
        KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ff8065c0000)
        USER32.dll => /cygdrive/c/WINDOWS/System32/USER32.dll (0x7ff8087d0000)
        win32u.dll => /cygdrive/c/WINDOWS/System32/win32u.dll (0x7ff806540000)
        GDI32.dll => /cygdrive/c/WINDOWS/System32/GDI32.dll (0x7ff807e30000)
        gdi32full.dll => /cygdrive/c/WINDOWS/System32/gdi32full.dll (0x7ff8069c0000)
        msvcp_win.dll => /cygdrive/c/WINDOWS/System32/msvcp_win.dll (0x7ff806be0000)
        cygwin1.dll => /usr/bin/cygwin1.dll (0x180040000)
        cygcrypto-1.1.dll => /usr/bin/cygcrypto-1.1.dll (0x3ff910000)
        ucrtbase.dll => /cygdrive/c/WINDOWS/System32/ucrtbase.dll (0x7ff806890000)
        cygz.dll => /usr/bin/cygz.dll (0x3fcd40000)
        advapi32.dll => /cygdrive/c/WINDOWS/System32/advapi32.dll (0x7ff808b00000)
        msvcrt.dll => /cygdrive/c/WINDOWS/System32/msvcrt.dll (0x7ff807270000)
        sechost.dll => /cygdrive/c/WINDOWS/System32/sechost.dll (0x7ff807370000)
        RPCRT4.dll => /cygdrive/c/WINDOWS/System32/RPCRT4.dll (0x7ff8089d0000)
        CRYPTBASE.DLL => /cygdrive/c/WINDOWS/SYSTEM32/CRYPTBASE.DLL (0x7ff805d30000)
        bcryptPrimitives.dll => /cygdrive/c/WINDOWS/System32/bcryptPrimitives.dll (0x7ff806360000)
        IMM32.DLL => /cygdrive/c/WINDOWS/System32/IMM32.DLL (0x7ff807240000)

C:\Users\at>c:\cygwin\bin\ssh at@ra
Confirm user presence for key ED25519-SK SHA256:[...]
init_winhello: WARNING! This should not be like this! WinHello API Error: Is user available=0, User=0.
(success)

I believe this can be made to work because Cygwin's DLLs work without C:\cygwin\bin in PATH, but I do not know how yet.

C:\Users\at>C:\cygwin\bin\ldd /usr/bin/cygcrypto-1.1.dll
        ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff808c10000)
        KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ff808710000)
        KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ff8065c0000)
        cygwin1.dll => /usr/bin/cygwin1.dll (0x180040000)
        cygz.dll => /usr/bin/cygz.dll (0x3fcd40000)
        advapi32.dll => /cygdrive/c/WINDOWS/System32/advapi32.dll (0x7ff808b00000)
        msvcrt.dll => /cygdrive/c/WINDOWS/System32/msvcrt.dll (0x7ff807270000)
        sechost.dll => /cygdrive/c/WINDOWS/System32/sechost.dll (0x7ff807370000)
        RPCRT4.dll => /cygdrive/c/WINDOWS/System32/RPCRT4.dll (0x7ff8089d0000)
        CRYPTBASE.DLL => /cygdrive/c/WINDOWS/SYSTEM32/CRYPTBASE.DLL (0x7ff805d30000)
        bcryptPrimitives.dll => /cygdrive/c/WINDOWS/System32/bcryptPrimitives.dll (0x7ff806360000)

I tested with an updated cygwin on Windows 10 2004.

init_winhello: Cannot load functions from dll

I'm fairly sure this is computer policy related.
winhello.dll is added tu /usr/bin but when calling ssh-keygen -w winhello.dll -t ecdsa-sk -f id_ecdsa_sk I get the above mentioned error. I checked the file properties for oddities, couldn't find any setting...

Switch to BSD license

Would it be possible switch to BSD license so this one can be used to implement PowerShell/Win32-OpenSSH#1804 ?