> * ssh(1), sshd(8): the RFC4254 connection/channels protocol provides
> a TCP-like window mechanism that limits the amount of data that
> can be sent without acceptance from the peer. In cases where this
> limit was exceeded by a non-conforming peer SSH implementation,
> ssh(1)/sshd(8) previously discarded the extra data. From OpenSSH
> 9.6, ssh(1)/sshd(8) will now terminate the connection if a peer
> exceeds the window limit by more than a small grace factor. This
> change should have no effect of SSH implementations that follow
> the specification.
I wonder how this affects things like HPNSSH. OpenSSH's very small window size makes connection transfers over high latency links slow to an absolute crawl without any way improve other than patching SSH or figuring out how to bypass SSH for the actual data transfer.
It is discuused here: https://lists.mindrot.org/pipermail/openssh-unix-dev/2023-De... - the HPN-SSH maintainer says "I do have an issue with [the OpenSSH 9.6] release in that it breaks interaction with HPN-SSH. The client seems to be window limited to 2MB sending regardless of what is being advertised by the receiver."
I wonder how this affects things like HPNSSH. OpenSSH's very small window size makes connection transfers over high latency links slow to an absolute crawl without any way improve other than patching SSH or figuring out how to bypass SSH for the actual data transfer.