implements unsupported version 0x00070000 (supported: 0x00090000)
BennyH26 opened this issue · 11 comments
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
Same problem here.
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.
I ran into this same issue when using OpenSSH_8.9p1, version OpenSSH_8.8p1 worked for me.
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.
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: #23
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
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.
@mgbowen I tried this, but the compilation failed. Let me try to see if I can find you the error for that.
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!
@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.
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
makeI 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 2However, adding
-DBUILD_TESTS=OFFworked.
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.