Repository navigation
Compiled OpenSSH 9.2.0.0 sshd can not be started due to entry point BN_set_flags could not be located #2052
Description
Prerequisites
- Write a descriptive title.
- Make sure you are able to repro it on the latest version
- Search the existing issues.
Steps to reproduce
I have compiled the openssh 9.2.0.0 with visual studio 2022
it finishes without problem while when I double click sshd.exe, it fails with error message below
The procedure entry point BN_set_flags could not be located in the dynamic link library.
Expected behavior
I have built the solution openssh 8.9.0.0 and it does not have such issue.
It is expected to be able to open sshd.exeActual behavior
it fails to be startedError details
No response
Environment data
Name Value
---- -----
PSVersion 5.1.19041.2673
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.19041.2673
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1Version
9.2.0.0
Visuals
No response
Reacted by Douglas Krahmer
Reacted by Nima Zareian and Chih-Hsuan Yen
Activity
danielo-unity3d commentedon Apr 5, 2023
I also hit this issue, but it was not the only one, as I tried to update the compiler to VS-2022 (
clversion 19.35.32216.1 for x64)... becausechocowas unable to installvcbuildtools.I 1st hit a link issue, that indicated that I needed to re-compile ZLib with the same compiler as OpenSSH, and so when I got the same error as mentioned here, I decided I also wanted to recompile LibreSSL with the updated compiler.
However, when I did that, I discovered that the naming of the LibreSSL libraries was not the same from what I built, and had difficulty gathering the dependencies as built by msbuild, so I tried with ninja... and then I gave up (for now).
The build system (and dependency management) is not so well documented (AFAICT), or well adapted to making this change, and there are a lot of moving parts (IMHO).
It should be migrated to use
vcpkg(see here), orconan, to manage the dependencies (ZLib, LibreSSL, libfido2), rather than relying oncontrib/win32/openssh/paths.targets.Also, the scripts should not try to install development tools through
choco(and instead just try to detect what is currently detected from the environment). Because, the way the scripts bootstrap the build, they (apparently) alter it from what would by done by default from the command-line (gathering artifacts)... based on my very brief exposure.That's my 2¢.
tgauth commentedon Apr 10, 2023
I think this is a LibreSSL compatibility issue that popped up when upgrading from LibreSSL v3.4.3 to v3.6.2. Win32-OpenSSH 9.2 is built with LibreSSL v3.6.2, but LibreSSL v3.4.3 is being found first in the path.
Can you ensure that libcrypto.dll is in the same folder as the binaries (
...\bin\x64\debug)? Copy over the libcrypto.dll that is in thecontrib\win32\openssh\libresslfoldersamhocevar commentedon Aug 24, 2023
Hi! I hit the same problem and I can confirm that copying the
libcrypto.dllfromcontribinto the executable directory causes the binaries to pick the right DLL and run properly.