-
Notifications
You must be signed in to change notification settings - Fork 365
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TimeOut connecting using 2.14.0 #642
Comments
I encountered this issue also. It stalled on kexinit and timed out. This only happened in Docker (but not even all Docker runtimes, because it worked on Docker on macOS but not on Linux). Downgrading to 2.13.2 fixed it. |
If this occurs only in some dockerized runs it stands to reason that the OS inside the docker container as well as the Java version inside the container might have an influence. @rgarciapariente , @proprietary : What OS is running inside your docker containers, and what Java version is being used? |
The interesting thing in the failing logs is that between encoding the KEX_INIT message and actually sending it a lot of time passes. If we take just one session, we have in the failing server log
That is... strange. Could that be because of using a strong random since to commit 3cc9d48? Can you try with that commit reverted? |
Yeah that actually worked https://gist.github.com/proprietary/bd31a15f29261480bf35512dbc743aeb |
So the problem was entropy starvation. |
As for PEBCAK the question is between which chair and whose keyboard :-). Guess both are mine. Sorry about that. I should have known about that potential problem, but somehow I had assumed that switching to a strong RNG was fine after I saw no detrimental effects neither locally nor in CI. I think the correct way forward is to revert that commit, and then enhance the random thing in Apache MINA sshd such that strong and "normal" RNGs can be configured separately. Most uses of the RNG don't have to use a strong RNG, but wherever the RNG is used to derive a key (for instance in the KEMs) using a strong RNG might make sense. In particular in |
This reverts commit 3cc9d48. Do _not_ use a strong RNG; it may run into entropy starvation. Just plain new SecureRandom() is good enough.
Done. Will be in the next release, and is available in the snapshot artifacts from the Apache Snapshots maven repository. @rgarciapariente , @proprietary: please test with the snapshot artifacts, and if successful, we can close this. |
Tested with 2.14.1-SNAPSHOT from the snapshot repository and it works on my environment with poor entropy. Thank you for your efforts. |
Same, it's work perfect. Thank you very much |
Thank you for confirming. |
@tomaswolf please release 2.14.1 version. |
Version
2.14.0
Bug description
We upgrade from 2.13.2 to 2.14.0, after that we see timeout in the connections. If we downgrade to 2.13.2 the issue dissapear
Actual behavior
Main log
ClientLog
ServerLog
Expected behavior
With 2.13.2 we have the next logs
Main log
Client Log
Server Log
Relevant log output
No response
Other information
We also test to disable SunJCEWrapper to check if the new feature is related
But we see the timeout and it seem not related to the issue.
The issue only happend in Docker image execution. In local with windows or wsl2 is not reproduced
The text was updated successfully, but these errors were encountered: