mgbowen / windows-fido-bridge

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.
Apache License 2.0
114 stars 15 forks source link

implements unsupported version 0x00070000 (supported: 0x00090000) #26

Closed BennyH26 closed 2 years ago

BennyH26 commented 2 years ago

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

alkampfergit commented 2 years ago

Same problem here.

BennyH26 commented 2 years ago

Are you using OpenSSH_8.9p1 also? I'm wondering if it's something with the portable version of this release that the package doesn't like.

Warriorrrr commented 2 years ago

I ran into this same issue when using OpenSSH_8.9p1, version OpenSSH_8.8p1 worked for me.

kyleposluns commented 2 years ago

How did you downgrade to OpenSSH_8.8p1 @Warriorrrr? I need this software to work for my job. I can't use Ubuntu version 20.04 because it has OpenSSH 8.2. I used to run Ubuntu 21.10 which I believe ran Open SSH 8.4, which worked fine. but when I upgraded to Ubuntu 22.04 LTS with OpenSSH 8.9 it does not work.

kyleposluns commented 2 years ago

Looks like the repository has not been updated: https://github.com/mgbowen/apt-repository/tree/master/debian/dists/bullseye/main/binary-amd64 to include this PR: https://github.com/mgbowen/windows-fido-bridge/pull/23

Warriorrrr commented 2 years ago

I used the following commands: (source: https://github.com/Allar/windows-fido-bridge/blob/main/README.md#requirements)

cd ~
sudo apt update && sudo apt install build-essential zlib1g-dev libssl-dev libpam0g-dev libselinux1-dev
wget -c https://cloudflare.cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-8.8p1.tar.gz
tar -xzf openssh-8.8p1.tar.gz
rm openssh-8.8p1.tar.gz
cd openssh-8.8p1
./configure --with-md5-passwords --with-pam --with-selinux --with-privsep-path=/var/lib/sshd/ --sysconfdir=/etc/ssh
sudo make install
cd ..
rm -rf openssh-8.8p1
mgbowen commented 2 years ago

Hi,

Instead of recompiling OpenSSH, you should compile windows-fido-bridge with the appropriate SK_API_VERSION. For OpenSSH 8.9 and higher, that is version 9. To do that, in the instructions for compiling for source, this should be your CMake invocation:

cmake -DCMAKE_BUILD_TYPE=Release -DSK_API_VERSION=9 ..

The default sk-api version is set to 7 because Debian bullseye includes OpenSSH 8.4.

kyleposluns commented 2 years ago

@mgbowen I tried this, but the compilation failed. Let me try to see if I can find you the error for that.

BennyH26 commented 2 years ago

Hi,

Instead of recompiling OpenSSH, you should compile windows-fido-bridge with the appropriate SK_API_VERSION. For OpenSSH 8.9 and higher, that is version 9. To do that, in the instructions for compiling for source, this should be your CMake invocation:

cmake -DCMAKE_BUILD_TYPE=Release -DSK_API_VERSION=9 ..

The default sk-api version is set to 7 because Debian bullseye includes OpenSSH 8.4.

This worked! Thank you so much for creating such an awesome bridge, maintaining such awesome online docs, and taking the time to respond to issues like this. You're a class act!

kyleposluns commented 2 years ago

@mgbowen The cmake command worked, but when I tried to run make I got this:

CMake Error at /usr/share/cmake-3.22/Modules/GoogleTestAddTests.cmake:83 (message):
  Error running test executable.

    Path: '/home/kyle/windows-fido-bridge/build/nested-windows-build/src/nested_windows-build/src/common/common_tests.exe'
    Result: Process terminated due to timeout
    Output:

Call Stack (most recent call first):
  /usr/share/cmake-3.22/Modules/GoogleTestAddTests.cmake:179 (gtest_discover_tests_impl)

make[5]: *** [src/common/CMakeFiles/common_tests.dir/build.make:175: src/common/common_tests.exe] Error 1
make[5]: *** Deleting file 'src/common/common_tests.exe'
make[4]: *** [CMakeFiles/Makefile2:375: src/common/CMakeFiles/common_tests.dir/all] Error 2
make[3]: *** [Makefile:166: all] Error 2
make[2]: *** [CMakeFiles/nested_windows.dir/build.make:86: nested-windows-build/src/nested_windows-stamp/nested_windows-build] Error 2
make[1]: *** [CMakeFiles/Makefile2:191: CMakeFiles/nested_windows.dir/all] Error 2
make: *** [Makefile:166: all] Error 2

However, adding -DBUILD_TESTS=OFF worked.

mgbowen commented 2 years ago

This worked! Thank you so much for creating such an awesome bridge, maintaining such awesome online docs, and taking the time to respond to issues like this. You're a class act!

Thanks, I appreciate the kind words :)

@mgbowen The cmake command worked, but when I tried to run make I got this:

CMake Error at /usr/share/cmake-3.22/Modules/GoogleTestAddTests.cmake:83 (message):
  Error running test executable.

    Path: '/home/kyle/windows-fido-bridge/build/nested-windows-build/src/nested_windows-build/src/common/common_tests.exe'
    Result: Process terminated due to timeout
    Output:

Call Stack (most recent call first):
  /usr/share/cmake-3.22/Modules/GoogleTestAddTests.cmake:179 (gtest_discover_tests_impl)

make[5]: *** [src/common/CMakeFiles/common_tests.dir/build.make:175: src/common/common_tests.exe] Error 1
make[5]: *** Deleting file 'src/common/common_tests.exe'
make[4]: *** [CMakeFiles/Makefile2:375: src/common/CMakeFiles/common_tests.dir/all] Error 2
make[3]: *** [Makefile:166: all] Error 2
make[2]: *** [CMakeFiles/nested_windows.dir/build.make:86: nested-windows-build/src/nested_windows-stamp/nested_windows-build] Error 2
make[1]: *** [CMakeFiles/Makefile2:191: CMakeFiles/nested_windows.dir/all] Error 2
make: *** [Makefile:166: all] Error 2

However, adding -DBUILD_TESTS=OFF worked.

Hmm, that's odd. My first guess would be Windows Defender/Real-time protection scanning the compiled test executable before executing it, and that scanning time combined with the actual test execution time causes the timeout. Running make test a few times might cause it to work correctly, but, of course, the better solution would be to increase the timeout (or find out why Windows takes so long to scan the file, if indeed that's the problem).

Either way, I'm glad you were able to get it to work with tests off. I'm going to go ahead and close this as the original issue was resolved; feel free to reopen it if you run into issues again.