Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
x/crypto/ssh: msgNewKeys interpreted too soon #18850
"We've also run into a different issue during the kex/handshake.
panic: ssh: no key material for msgNewKeys
We were previously running golang/crypto@ca7e7f1"
I took a look at this , but it's puzzling.
Can you confirm that your code runs cleanly under the race detector?
We run all our tests with the race detector and haven't had any complaints from that lately.
What would happen if a client sends a kex with FirstKexFollows set? I can try to test that (using dropbear), but it's just a guess at this point.
Since encryption messes up the packets, the wrongly retained packets look like noise and cause application protocol errors or panics in the SSH library. This normally triggers very rarely: the mandatory key exchange doesn't have parallel writes, so this failure condition would be setup on the first key exchange, take effect only after the second key exchange. Fortunately, the tests against openssh exercise this. This change adds also adds a unittest. Fixes golang#18850. Change-Id: I656c8b94bfb265831daa118f4d614a2f0c65d2af Reviewed-on: https://go-review.googlesource.com/36056 Reviewed-by: Brad Fitzpatrick <firstname.lastname@example.org> Run-TryBot: Han-Wen Nienhuys <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org>