Skip to content

Trying to repro Rekeying issue #1764 - #1774

Closed
mus65 wants to merge 1 commit into
sshnet:developfrom
mus65:rekeylimit
Closed

mus65 wants to merge 1 commit into
sshnet:developfrom
mus65:rekeylimit

Conversation

@mus65

@mus65 mus65 commented Mar 21, 2026

Copy link
Copy Markdown
Contributor

No description provided.

@mus65

mus65 commented Aug 13, 2026

Copy link
Copy Markdown
Contributor Author

Closing, see #1823

@mus65 mus65 closed this Aug 13, 2026
vlastee pushed a commit to vlastee/SSH.NET that referenced this pull request Sep 25, 2026
SendMessage checked the key exchange wait handle before acquiring the
socket write lock. When a server-initiated re-exchange started in that
window, the client's SSH_MSG_KEXINIT could be sent first, after which the
already in-flight data message violated RFC 4253 section 7.1. Strict
servers (e.g. ProFTPD mod_sftp) then fail the exchange or drop the
connection.

SendMessage now re-checks the wait handle while holding the write lock
and goes back to waiting when a re-exchange has started in the meantime.
The packet is also built entirely under the write lock, so a completing
re-exchange can no longer swap the client cipher, MAC or compression
state in the middle of building a packet.

The race does not reproduce against the OpenSSH test server (which is
why the attempt in sshnet#1774 stayed green): OpenSSH queues non key exchange
output while a re-exchange is in progress and tolerates the client data
that slips in. ProFTPD mod_sftp does not, so this adds an integration
test which reproduces the failure with concurrent SFTP uploads against
a ProFTPD server configured to re-key every 1 MB. Without the fix the
test failed 7 out of 8 runs; with it, it passes consistently.

Fixes sshnet#1764.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant