Fix a bug with server-side rekeying where the session state at hand
has been toggled to SSH_SESSION_STATE_AUTHENTICATED before performing
the packet send of the SSH2_MSG_USERAUTH_SUCCESS message.
Before this change, what can happen is that during the packet send,
the SSH2_MSG_USERAUTH_SUCCESS message can end up being queued due
to a small rekey data limit value. libssh server will then proceed
to attempt to send KEX-related rekeying messages to the client before
the client has received USERAUTH_SUCCESS. OpenSSH clients do not
expect to undergo rekeying before having been authenticated, and so
will exit with error when this happens.
The behavior before and after can be observed with the pkd test making
use of its new --rekey flag:
./pkd_hello -t torture_pkd_openssh_rsa_rsa_default -i1 --rekey=16 -v -v -v
A new CMake test entry is added for the above variation and can be run
with:
ARGS="-R pkd_hello_rekey" make test
Before the fix, the test will fail; after, the test succeeds while
performing rekeying once every 16 bytes.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
c0f3a96089