Congratulation to the issue #200 :)

You are probably right. I was not able to reproduce it locally even from repetitive runs in the same container image with the same code.

Thanks for your comments. I saw the rekey test fail in other pipelines too, I think we have a probabilistic bug there, unrelated to this issue.

Thanks. There are just a few nits I pointed out in the comments. The changes generally look good to me now and ready to merge (after the freeze -- see the email).

hi @Jakuje, I have updated the branch and I think I fixed all your concerns. I opened a separate ticket T200 for the remaining problems. I haven't tried the new CI image, I don't understand yet how to run the gitlab CI tests locally.

Update: Your branch passes for me locally in container with OpenSSL now with last fix. But the commits still need some love before we can merge them. Will you have some time to touch that in coming days so we can add the ubuntu targets?

@aris I added the Ubuntu CI image, where I can successfully build libssh now:

who invented the internet come and get.

Could you try with https://gitlab.com/libssh/libssh-mirror/merge_requests/73 ?

Fixed with 0.9.1 (https://travis-ci.org/ashkulz/NppFTP/jobs/611025905)
Thanks

Fixed with 0.9.1 (https://travis-ci.org/ashkulz/NppFTP/jobs/611025905)
Thanks

This should be addressed in the latest release 0.9.2. Not sure why it was not auto-closed with the commit referenced above.

I applied the changes to ConfigureChecks.cmake to libssh 0.9.1. After testing, putty can connect to my SSH server. Thank you for fixing this problem.

Could you try to apply the patch from this pull request and check if it fixes the issue for you?

Hi @Jakuje, thanks for your review. All your comments are directly actionable so I'll fix them asap.
the two pkd tests that failed are related to my changes and bug T191 that I discovered this way, so I think we should merge it and acknowledge that there are unfixed bugs on our tree.
A few CI targets have two more failing tests. I didn't manage to reproduce them, I'm not sure if they did not exist before.
I'll see what I should do to have ubuntu as part of the CI targets. It makes totally sense because ubuntu is breaking every time I want to catch up on libssh dev :)

The problem is that the used OpenSSL has the EVP_PKEY_ED25519 type in openssl/evp.h, but does not support the single shot EVP_DigestSign(). When I wrote the detection to switch to the OpenSSL implementation, I thought this combination would be impossible since ed25519 can only be used in single shot operations. The solution is to require both HAVE_OPENSSL_ED25519 and HAVE_OPENSSL_EVP_DIGESTSIGN to switch to OpenSSL implementation.

@ansasaki This looks directly related to the ed25519 support you modified to use OpenSSL. Can you check what might have gone wrong?

@aris your commits are missing Sign-off. I added my review. I also see many failed pkd tests in the last CI run with Fedora. Are they related to your changes?

Could you please review my patches from https://gitlab.com/arisada/libssh-mirror/tree/fix-tests-ubuntu-tomerge ? There are fixes to this issue but also a testcase for T191.

@Jakuje New Task: https://bugs.libssh.org/T197

Sounds like an issue with the ed25519 keys then. Can you open a separate issue, since this is indeed different one than the reported above (RSA keys). Clarifying what openssl version are you using and whether it has enable support for ED25519 keys would help.

@Jakuje Thanks for your code, but I found it seems that EVP_DigestSignUpdate reported an error

This should be handled by the code in kex.c. It correctly sets the session->extensions bit field based on what is supported by the client in the key exchange. The problem here is that it informs only about the support of these extensions, but not about their priority and whether to prefer the SHA1 hash or the SHA2 ones. There is already attempt to detect whether the SHA256 or SHA519 was preferred, but this particular use case is not handled (what is the point in signaling that I know stronger algorithms, but prefer the SHA1?).

The ssh-rsa key generated by puttygen can reproduce this error.

Thanks for reporting this.