mgbowen / windows-fido-bridge Goto Github PK
View Code? Open in Web Editor NEWAn OpenSSH SK middleware that allows you to use a FIDO/U2F security key (e.g. a YubiKey) to SSH into a remote server from WSL or Cygwin.
License: Apache License 2.0
An OpenSSH SK middleware that allows you to use a FIDO/U2F security key (e.g. a YubiKey) to SSH into a remote server from WSL or Cygwin.
License: Apache License 2.0
I am not sure when exactly it happened but at some point recently OpenSSH 8.4 was added to the buster-backports
repository.
See here: https://packages.debian.org/buster-backports/ssh and its dependencies.
My suggestion is for the documentation (Wiki?) and other related things (Like the apt repository) to mention and support the possibility of installing a supported version of SSH from backports instead of upgrading the entire system to Bullseye for one piece of software.
Of course upgrading to Bullseye is still a possibility and may be preferred for some users, but I feel most would prefer to use the backports package and they may not realise it exists without documentation here.
I am currently running Debian Buster in WSL2 with OpenSSH_8.4p1 Debian-2~bpo10+1
and the repository does not work with buster:
erisa@Tuturu:~$ ssh -V
OpenSSH_8.4p1 Debian-2~bpo10+1, OpenSSL 1.1.1d 10 Sep 2019
erisa@Tuturu:~$ sudo apt install windows-fido-bridge
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
windows-fido-bridge : Depends: windows-fido-bridge-skapiv5 but it is not going to be installed or
windows-fido-bridge-skapiv7 but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
erisa@Tuturu:~$ sudo apt install windows-fido-bridge windows-fido-bridge-skapiv5 windows-fido-bridge-skapiv7
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
windows-fido-bridge-skapiv5 : Depends: openssh-client (< 1:8.4) but 1:8.4p1-2~bpo10+1 is to be installed
Depends: libc6 (>= 2.30) but 2.28-10 is to be installed
Depends: libgcc-s1 (>= 3.0) but it is not installable
Depends: libstdc++6 (>= 9) but 8.3.0-6 is to be installed
Conflicts: windows-fido-bridge-skapiv7 but 1.1.0 is to be installed
windows-fido-bridge-skapiv7 : Depends: libc6 (>= 2.30) but 2.28-10 is to be installed
Depends: libgcc-s1 (>= 3.0) but it is not installable
Depends: libstdc++6 (>= 9) but 8.3.0-6 is to be installed
Conflicts: windows-fido-bridge-skapiv5 but 1.1.0 is to be installed
E: Unable to correct problems, you have held broken packages.
Installing from source appears to work okay, though under the default environment you have to specify the full SSH_SK_PROVIDER=/usr/local/lib/libwindowsfidobridge.so
for it to function.
Note that it is also required to specify -DSK_API_VERSION=7
to work with the OpenSSH 8.4 that backports supplies.
When I attempted, producing a package results in some.. strange things:
dpkg: error processing archive /home/erisa/windows-fido-bridge/build/windows-fido-bridge-skapiv7_1.1.0_amd64.deb (--unpack):
parsing file '/var/lib/dpkg/tmp.ci/control' near line 4:
field name 'windows-fido-bridge' must be followed by colon
dpkg: error processing archive /home/erisa/windows-fido-bridge/build/windows-fido-bridge_1.1.0_amd64.deb (--unpack):
parsing file '/var/lib/dpkg/tmp.ci/control' near line 3:
field name 'windows-fido-bridge' must be followed by colon
Errors were encountered while processing:
/home/erisa/windows-fido-bridge/build/windows-fido-bridge-skapiv7_1.1.0_amd64.deb
/home/erisa/windows-fido-bridge/build/windows-fido-bridge_1.1.0_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Unfortunately I don't know enough about the project or Debian packaging to begin to work this out myself, I hope my information helps in some way.
hello !
I'm unable to generate a key on a freshly installed wsl debian updated to bullseye, after instaling the packages from apt.mgbowen.dev repo.
Neither pin code or touch prompt are showing.
I got the same behavior with and without -Oapplication=ssh:windows-fido-bridge-verify-required
I'm using windows 10 1909 with a yubikey 5 nfc enrolled in windows hello.
There is the output with debugging enabled :
root@KATGL75:~# WINDOWS_FIDO_BRIDGE_DEBUG=true SSH_SK_PROVIDER=libwindowsfidobridge.so ssh-keygen -t ecdsa-sk -v -Oapplication=ssh:windows-fido-bridge-verify-required
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
debug1: start_helper: starting /usr/lib/openssh/ssh-sk-helper
debug1: sshsk_enroll: provider "libwindowsfidobridge.so", device "(null)", application "ssh:windows-fido-bridge-verify-required", userid "(null)", flags 0x01, challenge len 0
debug1: sshsk_enroll: using random challenge
debug1: sshsk_open: provider libwindowsfidobridge.so implements version 0x00070000
[2020-11-22 11:15:27.294] [wfb-middleware] [debug] Parameters from OpenSSH:
[2020-11-22 11:15:27.295] [wfb-middleware] [debug] Algorithm: 0
[2020-11-22 11:15:27.295] [wfb-middleware] [debug] Challenge:
[2020-11-22 11:15:27.296] [wfb-middleware] [debug] | 0 1 2 3 4 5 6 7 8 9 a b c d e f
[2020-11-22 11:15:27.296] [wfb-middleware] [debug] | 0000: ...
[2020-11-22 11:15:27.296] [wfb-middleware] [debug] | 0010: ...
[2020-11-22 11:15:27.296] [wfb-middleware] [debug] Application: "ssh:windows-fido-bridge-verify-required"
[2020-11-22 11:15:27.296] [wfb-middleware] [debug] Flags: 0b00000001
[2020-11-22 11:15:27.296] [wfb-middleware] [debug] PIN: (not present)
[2020-11-22 11:15:27.296] [wfb-middleware] [debug] Options:
[2020-11-22 11:15:27.296] [wfb-middleware] [debug] (No options provided)
terminate called after throwing an instance of 'std::runtime_error'
what(): End of stream
client_converse: receive: unexpected internal error
reap_helper: helper exited abnormally
Key enrollment failed: unexpected internal error
OpenSSH 8.4 was released on 9/27/2020 and with it brings an incremented SK API version (from v5 in 8.3 to v7 in 8.4). One notable benefit of the incremented API is support for requiring PIN entry to authenticate with a security key.
OpenSSH 8.4 release notes here.
Hi,
I'm using the bridge (installed from apt-repository) using the Ubuntu on Windows Community Preview WSL image (basically Ubuntu 21.04) on Windows 11. The good news is that the bridge works. However it takes almost 30-60 seconds after the following log message;
Confirm user presence for key ECDSA-SK SHA256:<data-was-here>
Before the pop-up is shown (ignore warning on bottom, that's because I waited too long)
Authentication using FIDO2 on Windows is working quickly.
Have you seen this error before? Do you know what might be happening? ...do I need to be running openssh 8.3+?
I see this error when running SSH_SK_PROVIDER=/usr/local/lib/libwindowsfidobridge.so ssh-keygen -t ecdsa-sk
:
Provider "/usr/local/lib/libwindowsfidobridge.so" implements unsupported version 0x00050000 (supported: 0x00040000)
I'm running Ubuntu 20.04.1 LTS, but I would expect it to be compatible with similar instructions as Debian mentioned in the README..
I'm not sure how to go about diagnosing, but happy to give any output if it's helpful.
MYLAPTOP:~%>ssh -V
OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f 31 Mar 2020
MYLAPTOP:~%>uname -a
Linux MYLAPTOP 4.4.0-18362-Microsoft #836-Microsoft Mon May 05 16:04:00 PST 2020 x86_64 x86_64 x86_64 GNU/Linux
MYLAPTOP:~%>lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.1 LTS
Release: 20.04
Codename: focal
Hello. Hopefully you can help me get this working. I'm trying to use Windows Hello (fingerprint, specifically) to an SSH to use with Github.
I built from source, following the instructions and installed with sudo make install
.
To generate a key pair, I ran:
SSH_SK_PROVIDER=/usr/local/lib/libwindowsfidobridge.so ssh-keygen -t ecdsa-sk
After a fairly long wait (#21?), I was prompted by the Windows Hello screen and touched the fingerprint reader.
Unfortunately, the result was unsuccessful:
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
[2023-09-01 21:39:59.472] [win32-bridge] [critical] Failed to parse attestation object: Invalid or unknown attestation object format
Key enrollment failed: invalid format
Please let me know if there's any debuggint information I can provide. I'm quite stuck. :(
Versions:
For key generation i use following:
SSH_SK_PROVIDER=libwindowsfidobridge.so ssh-keygen -t ecdsa-sk -Oapplication=ssh:windows-fido-bridge-verify-required
Then it asks me to confirm the key, with success.
Then i add public key to the server, with verify-required
before the key and save the file
And finally try to connect to my server via ssh -oSecurityKeyProvider=libwindowsfidobridge.so *****@*.*.*.*
which results into this:
Confirm user presence for key ECDSA-SK SHA256:NkBUzghWtXZDS415hNnZlGu1aJIXFE1U0evIhsXej6U
[2022-01-25 23:37:11.057] [wfb-middleware] [debug] Parameters from OpenSSH:
[2022-01-25 23:37:11.057] [wfb-middleware] [debug] Algorithm: 0
[2022-01-25 23:37:11.057] [wfb-middleware] [debug] Data:
[2022-01-25 23:37:11.057] [wfb-middleware] [debug] | 0 1 2 3 4 5 6 7 8 9 a b c d e f
[2022-01-25 23:37:11.057] [wfb-middleware] [debug] | 0000: 00 00 00 20 5a 15 64 a4 8a 45 b0 0d 77 50 e0 d0 ... Z.d..E..wP..
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 0010: 6a cc 7a ec fe ea a4 43 52 45 1a 5f bb e1 0d ac j.z....CRE._....
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 0020: 2f 29 d9 d5 32 00 00 00 05 61 64 6d 69 6e 00 00 /)..2....admin..
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 0030: 00 0e 73 73 68 2d 63 6f 6e 6e 65 63 74 69 6f 6e ..ssh-connection
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 0040: 00 00 00 09 70 75 62 6c 69 63 6b 65 79 01 00 00 ....publickey...
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 0050: 00 22 73 6b 2d 65 63 64 73 61 2d 73 68 61 32 2d ."sk-ecdsa-sha2-
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 0060: 6e 69 73 74 70 32 35 36 40 6f 70 65 6e 73 73 68 nistp256@openssh
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 0070: 2e 63 6f 6d 00 00 00 a2 00 00 00 22 73 6b 2d 65 .com......."sk-e
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 0080: 63 64 73 61 2d 73 68 61 32 2d 6e 69 73 74 70 32 cdsa-sha2-nistp2
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 0090: 35 36 40 6f 70 65 6e 73 73 68 2e 63 6f 6d 00 00 [email protected]..
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 00a0: 00 08 6e 69 73 74 70 32 35 36 00 00 00 41 04 34 ..nistp256...A.4
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 00b0: 88 81 ea e6 1f 08 12 1b 78 6d 9e 9f 13 cd 66 a7 ........xm....f.
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 00c0: d2 6a a6 1f 12 c1 fc 30 2a 79 3b 6f d9 1e 0a 9e .j.....0*y;o....
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 00d0: f1 c8 1e 7b 86 5e 4d 8f 3d de b0 ff 9d 0a a1 25 ...{.^M.=......%
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 00e0: 2a 63 1f 33 bc f4 5c 22 71 90 a9 bd 87 40 8b 00 *c.3..\"q....@..
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 00f0: 00 00 27 73 73 68 3a 77 69 6e 64 6f 77 73 2d 66 ..'ssh:windows-f
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 0100: 69 64 6f 2d 62 72 69 64 67 65 2d 76 65 72 69 66 ido-bridge-verif
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 0110: 79 2d 72 65 71 75 69 72 65 64 y-required
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] Application: "ssh:windows-fido-bridge-verify-required"
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] Key handle:
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 0 1 2 3 4 5 6 7 8 9 a b c d e f
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 0000: ec 68 9d 51 79 ab 48 b1 16 72 21 1c f3 fc 09 6c .h.Qy.H..r!....l
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 0010: 19 86 68 aa 98 89 06 ad 9c ec e4 07 9b 5c 2e 1f ..h..........\..
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 0020: 75 8f d1 10 27 41 b1 d8 1b 99 17 b9 b3 b4 40 ff u...'A........@.
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 0030: 8a 82 3d ea 6f ad eb fd d2 cb 63 01 75 bb 90 c4 ..=.o.....c.u...
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] | 0040: f9 87 e8 18 f4 00 ......
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] Flags: 0b00000001
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] PIN: (not present)
[2022-01-25 23:37:11.058] [wfb-middleware] [debug] Forcing user verification because the environment variable "WINDOWS_FIDO_BRIDGE_FORCE_USER_VERIFICATION" is set to any value
terminate called after throwing an instance of 'std::system_error'
what(): Failed to get WebAuthN assertion (NotAllowedError): The operation was canceled by the user.
terminate called after throwing an instance of 'std::runtime_error'
what(): End of stream
client_converse: receive: unexpected internal error
reap_helper: helper exited abnormally
sign_and_send_pubkey: signing failed for ECDSA-SK "/home/w7rus/.ssh/id_ecdsa_sk": unexpected internal error
I use OnlyKey as a FIDO key, running debug multiple times shows no difference in the output.
Now this is one that's perhaps not the biggest priority but serves as a minor annoyance for me.
If you try to manage your keys with an SSH Agent (Whether to forward them with -A
or another reason), the fido bridge will stop functioning at all.
Like so:
erisa@Tuturu:~$ eval `ssh-agent`
Agent pid 971
erisa@Tuturu:~$ ssh-add
Identity added: /home/erisa/.ssh/id_rsa (erisa@Tuturu)
Identity added: /home/erisa/.ssh/id_ecdsa_sk (erisa@Tuturu)
erisa@Tuturu:~$ ssh snug
sign_and_send_pubkey: signing failed for ECDSA-SK "/home/erisa/.ssh/id_ecdsa_sk" from agent: agent refused operation
erisa@snug: Permission denied (publickey,keyboard-interactive).
erisa@Tuturu:~$
Adding -vvv
to ssh
doesn't add any more information, makes me wonder if ssh-agent
has some way to debug what's happening.
Tested with both WSL 1 and WSL 2, running Debian 11/Bullseye.
Small extra note, to allow the bridge to function without the commandline option in the README I've done the following:
Host snug
SecurityKeyProvider /usr/local/lib/libwindowsfidobridge.so
HostName x.x.x.x.x
Port 22
User erisa
One of ssh keys relatively new feature gaining in popularity is the ability to sign data, especially useful for git commits but the middleware does not seem to support it. The exact command ran by git is the following:
ssh-keygen -Y sign -n git -f /home/XXX/.ssh/id_ed25519_sk.pub /tmp/.git_signing_buffer_tmpnDcbzm
But this result in the following error when used with the bridge:
$ SSH_SK_PROVIDER=libwindowsfidobridge.so ssh-keygen -Y sign -n git -f /home/XXX/.ssh/id_ed25519_sk.pub /tmp/.git_signing_buffer_tmpnDcbzm
Signing file /tmp/.git_signing_buffer_tmpnDcbzm
<3>WSL (29464) ERROR: UtilBindVsockAnyPort:297: bind failed 38
[2023-04-22 17:44:14.124] [linux-middleware] [critical] End of stream
Couldn't sign message: invalid format
Signing /tmp/.git_signing_buffer_tmpnDcbzm failed: invalid format
Is this a bug of is it just not supported ?
Hi,
when I try to install with apt I got the following error
windows-fido-bridge : Depends: windows-fido-bridge-skapiv5 but it is not going to be installed or
windows-fido-bridge-skapiv7 but it is not going to be installed
Am I missing something?
THanks in advance
I tried your bridge code and it works as expected locally. Out of curiosity I checked if key signing also works over remote desktop.
I expect the windows dialog to pop up and ask me to insert my key/touch the key. What happens instead is focus loss, the ssh process hangs and there are no windows popups.
When I insert the key before trying (in the remote computer, not the remoted into computer) there is an immediate error. I have sharing of local smartcards/windows hello and plug&play i insert later turned on.
I do not exclude the possibility that my remote computer is misconfigured.
Confirm user presence for key ECDSA-SK SHA256:IqzdIRTVy7tMYG86DNzRzJ4IDA0m86c87evwmTRTJQg
terminate called after throwing an instance of 'std::system_error'
what(): Failed to get WebAuthN assertion (ConstraintError): The requested operation is not supported.
terminate called after throwing an instance of 'std::runtime_error'
what(): End of stream
client_converse: receive: unexpected internal error
reap_helper: helper exited abnormally
sign_and_send_pubkey: signing failed for ECDSA-SK ".ssh/id_ecdsa_portainer": unexpected internal error
[email protected]: Permission denied (publickey).
Aside; opening the YubiKey Manager program before/after inserting the key works as expected.
$ ssh -V
OpenSSH_8.3p1, OpenSSL 1.1.1j 16 Feb 2021
Error I get:
Provider "libwindowsfidobridge.so" implements unsupported version 0x00070000 (supported: 0x00050000)
Option I've set:
cmake -SK_API_VERSION=5 -DCMAKE_BUILD_TYPE=Release ..
Did I get the cmake syntax wrong?
SSH version: OpenSSH_8.3p1 Ubuntu-1ubuntu0.1, OpenSSL 1.1.1f 31 Mar 2020
Windows build: 19041
When attempting to ssh into Github, the following error occurs:
sign_and_send_pubkey: signing failed for ECDSA-SK "/home/jasper/.ssh/id_ecdsa_sk": invalid format
Running with verbose mode enabled spits out the following line of interest: ssh_sk_sign: couldn't find device for key handle
but the key is definitely present as ssh-keygen -t ecdsa-sk
still works fine.
Also note that Github suppports security keys
Verbose output:
ssh -v [email protected]
OpenSSH_8.3p1 Ubuntu-1ubuntu0.1, OpenSSL 1.1.1f 31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to github.com [140.82.121.4] port 22.
debug1: Connection established.
debug1: identity file /home/jasper/.ssh/id_rsa type -1
debug1: identity file /home/jasper/.ssh/id_rsa-cert type -1
debug1: identity file /home/jasper/.ssh/id_dsa type -1
debug1: identity file /home/jasper/.ssh/id_dsa-cert type -1
debug1: identity file /home/jasper/.ssh/id_ecdsa type -1
debug1: identity file /home/jasper/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/jasper/.ssh/id_ecdsa_sk type 10
debug1: identity file /home/jasper/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/jasper/.ssh/id_ed25519 type 3
debug1: identity file /home/jasper/.ssh/id_ed25519-cert type -1
debug1: identity file /home/jasper/.ssh/id_ed25519_sk type -1
debug1: identity file /home/jasper/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/jasper/.ssh/id_xmss type -1
debug1: identity file /home/jasper/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.3p1 Ubuntu-1ubuntu0.1
debug1: Remote protocol version 2.0, remote software version babeld-cec9758f
debug1: no match: babeld-cec9758f
debug1: Authenticating to github.com:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512
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: ssh-rsa SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /home/jasper/.ssh/known_hosts:5
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/jasper/.ssh/id_rsa
debug1: Will attempt key: /home/jasper/.ssh/id_dsa
debug1: Will attempt key: /home/jasper/.ssh/id_ecdsa
debug1: Will attempt key: /home/jasper/.ssh/id_ecdsa_sk ECDSA-SK SHA256:ODM140lacOLy6If+H9TqyGrgkWURB0bC7rIQ77tgLy0 authenticator
debug1: Will attempt key: /home/jasper/.ssh/id_ed25519 ED25519 SHA256:TgKJ3LbTxWSNlKFswegnc/nHijRfwXKYkpFcanVziDg
debug1: Will attempt key: /home/jasper/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/jasper/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/jasper/.ssh/id_rsa
debug1: Trying private key: /home/jasper/.ssh/id_dsa
debug1: Trying private key: /home/jasper/.ssh/id_ecdsa
debug1: Offering public key: /home/jasper/.ssh/id_ecdsa_sk ECDSA-SK SHA256:ODM140lacOLy6If+H9TqyGrgkWURB0bC7rIQ77tgLy0 authenticator
debug1: Server accepts key: /home/jasper/.ssh/id_ecdsa_sk ECDSA-SK SHA256:ODM140lacOLy6If+H9TqyGrgkWURB0bC7rIQ77tgLy0 authenticator
Confirm user presence for key ECDSA-SK SHA256:ODM140lacOLy6If+H9TqyGrgkWURB0bC7rIQ77tgLy0
debug1: start_helper: starting /usr/lib/openssh/ssh-sk-helper
debug1: ssh-sk-helper: ready to sign with key ECDSA-SK, provider internal: msg len 245, compat 0x0
debug1: sshsk_sign: provider "internal", key ECDSA-SK, flags 0x01
debug1: find_device: fido_dev_info_manifest: FIDO_ERR_INTERNAL
// Notice the following line:
debug1: ssh_sk_sign: couldn't find device for key handle
debug1: sshsk_sign: sk_sign failed with code -1
debug1: ssh-sk-helper: Signing failed: invalid format
debug1: ssh-sk-helper: reply len 8
debug1: client_converse: helper returned error -4
debug1: identity_sign: sshkey_sign: invalid format
sign_and_send_pubkey: signing failed for ECDSA-SK "/home/jasper/.ssh/id_ecdsa_sk": invalid format
debug1: Offering public key: /home/jasper/.ssh/id_ed25519 ED25519 SHA256:TgKJ3LbTxWSNlKFswegnc/nHijRfwXKYkpFcanVziDg
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/jasper/.ssh/id_ed25519_sk
debug1: Trying private key: /home/jasper/.ssh/id_xmss
debug1: No more authentication methods to try.
[email protected]: Permission denied (publickey).
Hi,
I can't use the generated key to log with ssh (There are no problems generating the key)
Installed the bridge via apt-get on Debian GNU/Linux bullseye/sid
and running ssh OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1j 16 Feb 2021
Yubikey neo with firmware 3.3.0
Also tried with a more recent Yubikey 5 with firmware 5.1.2
Both have the same exact results
Keys have 600 permission for the private key and 644 for the pub key
When trying to call with ssh (used -T
for testing it) it fails with the error
sign_and_send_pubkey: signing failed for ECDSA-SK "/home/tspascoal/.ssh/id_ecdsa_sk": invalid format
When doing the same with -vvvT
I get this (relevant snippet I believe) from the logs
debug1: Offering public key: /home/tspascoal/.ssh/id_ecdsa_sk ECDSA-SK SHA256:REDACTED authenticator
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: /home/tspascoal/.ssh/id_ecdsa_sk ECDSA-SK SHA256:REDACTED authenticator
debug3: sign_and_send_pubkey: ECDSA-SK SHA256:REDACTED
debug3: sign_and_send_pubkey: signing using [email protected] SHA256:REDACTED
Confirm user presence for key ECDSA-SK SHA256:REDACTED
debug3: start_helper: started pid=790
debug3: ssh_msg_send: type 5
debug3: ssh_msg_recv entering
debug1: start_helper: starting /usr/lib/openssh/ssh-sk-helper
debug1: ssh-sk-helper: ready to sign with key ECDSA-SK, provider internal: msg len 280, compat 0x0
debug1: sshsk_sign: provider "internal", key ECDSA-SK, flags 0x01
debug1: sk_probe: 0 device(s) detected
debug1: ssh_sk_sign: failed to find sk
debug1: sshsk_sign: sk_sign failed with code -1
debug1: ssh-sk-helper: Signing failed: invalid format
debug1: ssh-sk-helper: reply len 8
debug3: ssh_msg_send: type 5
debug1: client_converse: helper returned error -4
debug3: reap_helper: pid=790
debug1: identity_sign: sshkey_sign: invalid format
sign_and_send_pubkey: signing failed for ECDSA-SK "/home/tspascoal/.ssh/id_ecdsa_sk": invalid format
There was no windows dialog to authorize the use of the key (like it happened when the key was generated)
The problem probably lies in this line debug1: sk_probe: 0 device(s) detected
line. (don't know if this generated by the helper or by the bridge though)
I've tried to generate with and without -Oapplication=ssh:windows-fido-bridge-verify-required
I've also defined env variables WINDOWS_FIDO_BRIDGE_DEBUG=1
but doesn't seem to produce any extra output
Is there something I can do to diagnose the problem?
Thank you
P.S. I've tried with git for windows bash shell and this works fine as long as the shell is started with elevated privileges
I'm running on a 2020 Dell XPS 13 9310 with Windows 10 Enterprise, I've had the following issue on WSL2 with Ubuntu 20.04 20.10, and all versions of Debian I could get the install to work.
I'm using a Trezor Model T plugged in via direct USB-C, I know I'm giving too much information, I have a feeling this issue may be caused by my specific config/workstation.
When I attempt to generate a key, it does bring up the Fido2 Windows prompt, I auth the request on the Trezor Model T screen, and once it returns it seems to error out on the CLI terminate called after throwing an instance of 'std::out_of_range'
kristianfjones@DESKTOP-IP61DKN:/usr/lib$ WINDOWS_FIDO_BRIDGE_DEBUG=true SSH_SK_PROVIDER=libwindowsfidobridge.so ssh-keygen -v -t ecdsa-sk
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
debug1: start_helper: starting /usr/lib/openssh/ssh-sk-helper
debug1: sshsk_enroll: provider "libwindowsfidobridge.so", device "(null)", application "ssh:", userid "(null)", flags 0x01, challenge len 0
debug1: sshsk_enroll: using random challenge
debug1: sshsk_open: provider libwindowsfidobridge.so implements version 0x00070000
[2021-01-27 11:15:34.951] [wfb-middleware] [debug] Parameters from OpenSSH:
[2021-01-27 11:15:34.951] [wfb-middleware] [debug] Algorithm: 0
[2021-01-27 11:15:34.951] [wfb-middleware] [debug] Challenge:
[2021-01-27 11:15:34.951] [wfb-middleware] [debug] | 0 1 2 3 4 5 6 7 8 9 a b c d e f
[2021-01-27 11:15:34.951] [wfb-middleware] [debug] | 0000: 58 c5 d0 6f 35 86 0d 0c 63 17 59 9d ef 94 aa d8 X..o5...c.Y.....
[2021-01-27 11:15:34.951] [wfb-middleware] [debug] | 0010: 32 06 fc 04 57 83 19 03 3a 4d ca 4f c6 81 0a 12 2...W...:M.O....
[2021-01-27 11:15:34.951] [wfb-middleware] [debug] Application: "ssh:"
[2021-01-27 11:15:34.951] [wfb-middleware] [debug] Flags: 0b00000001
[2021-01-27 11:15:34.951] [wfb-middleware] [debug] PIN: (not present)
[2021-01-27 11:15:34.951] [wfb-middleware] [debug] Options:
[2021-01-27 11:15:34.951] [wfb-middleware] [debug] (No options provided)
terminate called after throwing an instance of 'std::out_of_range'
what(): map::at
client_converse: receive: unexpected internal error
reap_helper: helper exited abnormally
Key enrollment failed: unexpected internal error
kristianfjones@DESKTOP-IP61DKN:/usr/lib$ uname -r
5.4.72-microsoft-standard-WSL2
I was first running the Nathan Chance WSL2 custom kernel and I reverted back to the standard Microsoft WSL2 kernel to ensure that wasn't the issue.
I added the apt repository and am on Ubuntu 22.04 in WSL2, which has OpenSSH_8.9p1 Ubuntu-3, OpenSSL 3.0.2.
I get an error message Provider "libwindowsfidobridge.so" dlopen failed: Exec format error
when trying to use the fido bridge.
Back in march I think I had a working setup and I probably updated cygwin since.
When I tried to connect now, I got a signing failed error (a transcript of the essential messages is below).
I regenerated some keys using ssh-keygen -t ecdsa-sk
which generated the popop where I could select my physical key to add as 2FA.
I also recompiled the dll, ensured (through strace) that it is using the one I expected
OpenSSH_9.3p1, OpenSSL 1.1.1t 7 Feb 2023
debug1: identity file /cygdrive/d/....../.ssh/id_ecdsa_sk type 10
debug1: Will attempt key: /cygdrive/d/........./.ssh/id_ecdsa_sk ECDSA-SK SHA256:Udm3GW19WwtoBwo00IalCv1bDP0xdXX9KUCZje6wy4E authenticator
debug1: Trying private key: /cygdrive/d/......../.ssh/id_ecdsa
debug1: Offering public key: /cygdrive/d/......../.ssh/id_ecdsa_sk ECDSA-SK SHA256:Udm3GW19WwtoBwo00IalCv1bDP0xdx79KUCZje6wy4E authenticator
debug1: Server accepts key: /cygdrive/d/......../.ssh/id_ecdsa_sk ECDSA-SK SHA256:Udm3GW19WwtoBwo00IalCv1bDP0xdx79KUCZje6wy4E authenticator
debug1: start_helper: starting /usr/sbin/ssh-sk-helper
debug1: process_sign: ready to sign with key ECDSA-SK, provider internal: msg len 246, compat 0x4000000
debug1: sshsk_sign: provider "internal", key ECDSA-SK, flags 0x00
debug1: ssh_sk_sign: fido_dev_get_assert: FIDO_ERR_UNSUPPORTED_OPTION
debug1: sshsk_sign: sk_sign failed with code -2
debug1: ssh-sk-helper: Signing failed: requested feature not supported
debug1: main: 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 "/cygdrive/d/......./.ssh/id_ecdsa_sk": requested feature not supported
WSL2 Ubuntu 20.10 groovy
$ make -j $(nproc)
...
windows-fido-bridge/src/common/include/windows_fido_bridge/util.hpp:7:10: fatal error: span: No such file or directory
7 | #include <span>
| ^~~~~~
compilation terminated.
Less of an issue and more of a curiosity:
When I create or use an SSH key via my security key under Windows it asks for my security keys PIN, which is fair. The curious thing to me is that if I take the same keypair to Linux and present the security key, it only asks me to touch and not to supply any kind of PIN, even though the keypair was setup with one.
Wondering if this is an intentional design of windows fido bridge, some jankiness from the windows FIDO2/U2F api or something else beyond my understanding
To be clear I'm using a Solo Key 4.0.0 so if you can't reproduce it with another key then that's perfectly fair enough, mostly just curious if it's anything anyone knows about.
Hi,
I have updated my copy of ssh on Windows to 8.9, which does support fido2 keys. I notice that when I am connecting to a server that uses my YubiKey resident key from Windows, it does prompt me to enter the 4 digit pin.
However when using this bridge from WSL2, I only need to touch my finger to the sensor and it doesn't require me to enter my pin.
I would prefer to have it ask for my pin as well. Is there any way of setting this behaviour so it matches Windows?
I saw that Ed25519 isn't supported because Microsoft doesn't expose it, but I found what appears to be a very similar project that supports it: https://github.com/tavrez/openssh-sk-winhello. I'm not familiar with Windows Hello or FIDO2 really, but could this project perhaps do a similar thing? Or does it actually accomplish a different goal than that project?
There's been quite a few changes since the last release in November 2020, notably Cygwin and Ed25519 support. A new release would be convenient.
Before releasing a new version, remember to flip the README examples from ECDSA to Ed25519.
I upgraded my WSL to ubuntu 22.04, then recompiled the current master branch of this project. I now get this error when trying to connect:
Confirm user presence for key ED25519-SK SHA256:CENSORED-ID
debug1: start_helper: starting /usr/lib/openssh/ssh-sk-helper
debug1: process_sign: ready to sign with key ED25519-SK, provider /usr/local/lib/libwindowsfidobridge.so: msg len 270, compat 0x4000000
debug1: sshsk_sign: provider "/usr/local/lib/libwindowsfidobridge.so", key ED25519-SK, flags 0x21
debug1: sshsk_open: provider /usr/local/lib/libwindowsfidobridge.so implements version 0x00070000
Provider "/usr/local/lib/libwindowsfidobridge.so" implements unsupported version 0x00070000 (supported: 0x00090000)
debug1: ssh-sk-helper: Signing failed: invalid format
debug1: main: reply len 8
debug1: client_converse: helper returned error -4
debug1: identity_sign: sshkey_sign: invalid format
It seems the problem is the protocol version, see this line: Provider "/usr/local/lib/libwindowsfidobridge.so" implements unsupported version 0x00070000 (supported: 0x00090000)
The ssh version is OpenSSH_8.9p1 Ubuntu-3, OpenSSL 3.0.2 15 Mar 2022
Small note that I am doing this on Debian 10 Buster, following the instructions in the readme, and I have essentially no experience with CMake myself. I originally used WSL1 but tested with WSL2 and on a different machine to verify the bug.
The error seems to indicate it likely isn't related to any specific Debian release.
The important part seems to be:
[ 11%] Creating directories for 'mingw_stdthreads-populate'
[ 22%] Performing download step (git clone) for 'mingw_stdthreads-populate'
Cloning into 'mingw_stdthreads-src'...
fatal: reference is not a tree: c01463398bd2b09c2afa0cd06c12d7b1cc8a470d
CMake Error at mingw_stdthreads-subbuild/mingw_stdthreads-populate-prefix/tmp/mingw_stdthreads-populate-gitclone.cmake:40 (message):
Failed to checkout tag: 'c01463398bd2b09c2afa0cd06c12d7b1cc8a470d'
And for completeness here's the full log:
erisa@Tuturu:~/windows-fido-bridge/build$ cmake -DCMAKE_BUILD_TYPE=Release ..
-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Executing inside WSL: ON
-- Version: 7.0.1
-- Build type: Release
-- CXX_STANDARD: 20
-- Performing Test has_std_20_flag
-- Performing Test has_std_20_flag - Failed
-- Performing Test has_std_2a_flag
-- Performing Test has_std_2a_flag - Success
-- Performing Test SUPPORTS_USER_DEFINED_LITERALS
-- Performing Test SUPPORTS_USER_DEFINED_LITERALS - Success
-- Performing Test FMT_HAS_VARIANT
-- Performing Test FMT_HAS_VARIANT - Success
-- Required features: cxx_variadic_templates
-- Looking for strtod_l
-- Looking for strtod_l - not found
-- Build spdlog: 1.7.0
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Build type: Release
-- Could NOT find PythonInterp (missing: PYTHON_EXECUTABLE)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/erisa/windows-fido-bridge/build
erisa@Tuturu:~/windows-fido-bridge/build$ make -j16
Scanning dependencies of target nested_windows
Scanning dependencies of target fmt
Scanning dependencies of target gtest
[ 2%] Creating directories for 'nested_windows'
[ 7%] Building CXX object _deps/fmt-build/CMakeFiles/fmt.dir/src/format.cc.o
[ 7%] Building CXX object _deps/fmt-build/CMakeFiles/fmt.dir/src/os.cc.o
[ 9%] No download step for 'nested_windows'
[ 11%] Building CXX object _deps/googletest-build/googletest/CMakeFiles/gtest.dir/src/gtest-all.cc.o
[ 14%] No update step for 'nested_windows'
[ 16%] No patch step for 'nested_windows'
[ 19%] Performing configure step for 'nested_windows'
-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- Check for working C compiler: /usr/bin/x86_64-w64-mingw32-gcc
-- Check for working C compiler: /usr/bin/x86_64-w64-mingw32-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/x86_64-w64-mingw32-g++
[ 21%] Linking CXX static library libfmt.a
-- Check for working CXX compiler: /usr/bin/x86_64-w64-mingw32-g++ -- works
-- Detecting CXX compiler ABI info
[ 21%] Built target fmt
Scanning dependencies of target spdlog
[ 26%] Building CXX object _deps/spdlog-build/CMakeFiles/spdlog.dir/src/spdlog.cpp.o
[ 26%] Building CXX object _deps/spdlog-build/CMakeFiles/spdlog.dir/src/stdout_sinks.cpp.o
[ 30%] Building CXX object _deps/spdlog-build/CMakeFiles/spdlog.dir/src/file_sinks.cpp.o
[ 30%] Building CXX object _deps/spdlog-build/CMakeFiles/spdlog.dir/src/color_sinks.cpp.o
[ 33%] Building CXX object _deps/spdlog-build/CMakeFiles/spdlog.dir/src/async.cpp.o
[ 35%] Building CXX object _deps/spdlog-build/CMakeFiles/spdlog.dir/src/cfg.cpp.o
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Executing inside WSL: ON
make[3]: Entering directory '/home/erisa/windows-fido-bridge/build/nested-windows-build/src/nested_windows-build/_deps/mingw_stdthreads-subbuild'
make[4]: Entering directory '/home/erisa/windows-fido-bridge/build/nested-windows-build/src/nested_windows-build/_deps/mingw_stdthreads-subbuild'
make[5]: Entering directory '/home/erisa/windows-fido-bridge/build/nested-windows-build/src/nested_windows-build/_deps/mingw_stdthreads-subbuild'
Scanning dependencies of target mingw_stdthreads-populate
make[5]: Leaving directory '/home/erisa/windows-fido-bridge/build/nested-windows-build/src/nested_windows-build/_deps/mingw_stdthreads-subbuild'
make[5]: Entering directory '/home/erisa/windows-fido-bridge/build/nested-windows-build/src/nested_windows-build/_deps/mingw_stdthreads-subbuild'
[ 11%] Creating directories for 'mingw_stdthreads-populate'
[ 22%] Performing download step (git clone) for 'mingw_stdthreads-populate'
Cloning into 'mingw_stdthreads-src'...
fatal: reference is not a tree: c01463398bd2b09c2afa0cd06c12d7b1cc8a470d
CMake Error at mingw_stdthreads-subbuild/mingw_stdthreads-populate-prefix/tmp/mingw_stdthreads-populate-gitclone.cmake:40 (message):
Failed to checkout tag: 'c01463398bd2b09c2afa0cd06c12d7b1cc8a470d'
make[5]: *** [CMakeFiles/mingw_stdthreads-populate.dir/build.make:92: mingw_stdthreads-populate-prefix/src/mingw_stdthreads-populate-stamp/mingw_stdthreads-populate-download] Error 1
make[5]: Leaving directory '/home/erisa/windows-fido-bridge/build/nested-windows-build/src/nested_windows-build/_deps/mingw_stdthreads-subbuild'
make[4]: *** [CMakeFiles/Makefile2:76: CMakeFiles/mingw_stdthreads-populate.dir/all] Error 2
make[4]: Leaving directory '/home/erisa/windows-fido-bridge/build/nested-windows-build/src/nested_windows-build/_deps/mingw_stdthreads-subbuild'
make[3]: *** [Makefile:84: all] Error 2
make[3]: Leaving directory '/home/erisa/windows-fido-bridge/build/nested-windows-build/src/nested_windows-build/_deps/mingw_stdthreads-subbuild'
CMake Error at /usr/share/cmake-3.16/Modules/FetchContent.cmake:915 (message):
Build step for mingw_stdthreads failed: 2
Call Stack (most recent call first):
/usr/share/cmake-3.16/Modules/FetchContent.cmake:1006 (__FetchContent_directPopulate)
cmake/BuildMingwStdThreads.cmake:16 (FetchContent_Populate)
CMakeLists.txt:34 (include)
-- Configuring incomplete, errors occurred!
See also "/home/erisa/windows-fido-bridge/build/nested-windows-build/src/nested_windows-build/CMakeFiles/CMakeOutput.log".
make[2]: *** [CMakeFiles/nested_windows.dir/build.make:107: nested-windows-build/src/nested_windows-stamp/nested_windows-configure] Error 1
make[1]: *** [CMakeFiles/Makefile2:202: CMakeFiles/nested_windows.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 38%] Linking CXX static library ../../../lib/libgtest.a
[ 38%] Built target gtest
[ 40%] Linking CXX static library libspdlog.a
[ 40%] Built target spdlog
make: *** [Makefile:163: all] Error 2
erisa@Tuturu:~/windows-fido-bridge/build$
Seems like probably an upstream issue with mingw_stdthreads-populate
but I can't find a whole lot of information on that.
Normally if it was something I understood I would have gone down my own rabbit hole of debugging but this is entirely out of my understanding and I can't find sufficient information to get started with it.
See below comment.
Receiving this error message when attempting to run ssh-keygen
command:
Generating public/private ecdsa-sk key pair. You may need to touch your authenticator to authorize key generation. Provider "/usr/local/lib/libwindowsfidobridge.so" implements unsupported version 0x00070000 (supported: 0x00090000) Key enrollment failed: invalid format
I'm running WSL2; Ubuntu 22.04 LTS
ssh -V
OpenSSH_8.9p1 Ubuntu-3, OpenSSL 3.0.2 15 Mar 2022
I suggest to strip the debug information from the DLL - it saves about 12MB.
$ ls -l /usr/local/lib/cygwindowsfidobridge.dll
-rwxr-xr-x 1 13725074 Mar 24 13:05 /usr/local/lib/cygwindowsfidobridge.dll
$ strip /usr/local/lib/cygwindowsfidobridge.dll
$ ls -l /usr/local/lib/cygwindowsfidobridge.dll
-rwxr-xr-x 1 1622528 Mar 24 13:05 /usr/local/lib/cygwindowsfidobridge.dll
Thanks for project, it's very helpful!
Do you have any advice on if it's possible somehow to copy resident keys?
e.g.
$ ssh-add -K -v -S /usr/lib/libwindowsfidobridge.so
Enter PIN for authenticator:
debug1: start_helper: starting /usr/lib/openssh/ssh-sk-helper
debug1: sshsk_load_resident: provider "/usr/lib/libwindowsfidobridge.so", have-pin
debug1: sshsk_open: provider /usr/lib/libwindowsfidobridge.so implements version 0x00070000
Provider "/usr/lib/libwindowsfidobridge.so" returned failure -2
debug1: ssh-sk-helper: sshsk_load_resident failed: requested feature not supported
debug1: ssh-sk-helper: reply len 8
debug1: client_converse: helper returned error -59
Unable to load resident keys: requested feature not supported
Provider "/usr/local/lib/libwindowsfidobridge.so" implements unsupported version 0x00090000 (supported: 0x000a0000)
$ ssh -V
OpenSSH_9.1p1, OpenSSL 3.0.7 1 Nov 2022
Since Windows Hello is FIDO2 certified, should it be possible to use the bridge to use Windows Hello (essentially using the TPM to sign etc)
What kind of work needs to be done to support it?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.