x/crypto/ssh: bad kexinit during handshake #18711
Comments
|
Here's |
|
Looks like some flavor of #15066 reappearing (sigh) |
|
@hanwen I'm curious, is the information provided in this issue sufficient or is more information needed to assess the bug and ultimately fix it? I don't feel capable of fixing the problem on my own but I'm happy to provide more information/investigate if necessary. |
|
your info is not sufficient to be sure, but I suspect you could repro by adding sleep statements in the right places (see #15066). if you could that would be helpful. I'm a bit swamped with normal work, but I'll try to have a look tonight. |
|
I tried creating a repro by sprinkling the handshake part of the golang ssh crypto lib with some sleeps but was not able make it work. I'm also tried reproducing the original error that led to this issue being raised without luck so far. Is my understanding of this issue correct that this is probaply caused because the openssh client receives a |
|
almost: the first kex is special because it is mandatory, and I think the Go code has a race where the remote request for the first kex is somehow interpreted as a second kex, which then fires during the user authentication stage. (the word "handshake" is a bit overloaded here: there is the kex which has the dual purpose of setting up the secure channel and verifying the server identity, and there is authentication which verifies the user identity) technically, OpenSSH is not following the spec, since it should be legal to request a kex during user authentication, but in practice it doesn't make sense, and is apparently not implemented. It suggests that OpenSSH doesn't have proper layering in their code (something which you can also tell from the zlib@openssh.org compression method, which switches on compression after the user auth succeeded). |
|
I'm still failing at creating a somewhat reliable repro here. I managed to hit that bug once with |
|
@hanwen I created a repro for this error: https://github.com/databus23/golang-issue-18711 Unfortunately I wasn't able to trigger this bug in a single run by adding sleep statements in the right places but instead went for a test case the loops until the error occurs. At least on my computer this usually triggers the error with 30 seconds. Some observations I made in the process:
|
|
Reverting |
|
We've also run into a different issue during the kex/handshake. This is on a server running on golang/crypto@41d678d We were previously running golang/crypto@ca7e7f1 |
|
@belak While your problem also happens at the handshake phase it seems unrelated to the issue described here. This issue has been handled in https://go-review.googlesource.com/#/c/35851/ and was merged as golang/crypto@6fb0668. |
|
@hanwen Thanks again for taking this. I can confirm that with the merged fix, I can't reproduce the issue anymore. |
|
opened issue 18850 for the msgNewKeys problem. |
|
issue #18850 , that is. |
|
Looking good so far in my pipeline, thanks again! |
|
Hi, I am still hitting this issue, even though I have the golang/x/crypto commit mentioned above in my code. (I am at dc137be). OpenSSH fails to connect with: |
|
Same as @immesys. When it failsWhen it works |
|
Can we get this issue reopened? @hanwen I believe is the maintainer of this part of the code. |
|
Sure. Reopening for @hanwen. |
|
Although I will say that with 641ab6b I have not seen this again. If someone can confirm that in the ~10 commits that have happened in the past two weeks that one of those could plausibly have fixed this problem (with 641ab6b being the one that looks most likely) then I am happy to leave this closed. |
|
I cannot reproduce after an update 👍 |
What version of Go are you using (
go version)?1.7.x
What operating system and processor architecture are you using (
go env)?Linux, amd64
What operating system and processor architecture are you using (
go env)?What did you do?
Initiate a SSH connection.
What did you expect to see?
Successful handshake and healthy connection.
What did you see instead?
After upgrading
x/crypto/sshto golang/crypto@2e74c77 to fix #18439 I'm seeing handshakes fail occasionally with the following message coming from thesshclient:Type 20 being
SSH_MSG_KEXINIT. Maybe that's firing concurrently with the handshake or something? It appears to be flaky./cc @hanwen
The text was updated successfully, but these errors were encountered: