server: fix queued USERAUTH_SUCCESS rekey bug

Authored by simonsj on Apr 24 2019, 7:41 PM.


server: fix queued USERAUTH_SUCCESS rekey bug

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

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>


asnApr 29 2019, 2:00 PM
rLIBSSH7ef2fe7f7b21: packet: log when data-based rekeying needed