Binaries: We now have binaries for HPN-SSH. Currently just rpms but you'll find them under the RPMS folder. Debian packages are coming soon. Patches, for those that like to roll their own, are now under Patches. The binaries are meant as a drop in replacement for OpenSSH so the RPMs will install into the default locations and clobber existing installs. Important News: Versions 14v15 for OpenSSH 7.6 through version 14v18 for OpenSSH 7.8 had bug in the multithreaded AES-CTR code that would cause occasional hangs. We believe we've identified and fixed this problem. If you run into any issues please contact at hpn-ssh@psc.edu. We can't fix problems we don't know about so we are counting on you. Contact us: I have no idea who is using HPN-SSH and I'd really like to know. If you are using our code please drop us a line at hpn-ssh@psc.edu and tell me. Likewise, if you run into any problems, bugs, or have a feature request let us know. Donations: Lastly, initially I was funded by a generous grant from Cisco, the NSF, and NIH. That money is long long gone by now and I can only work on HPN-SSH when I have the time. If I can get some donations to the project at http://www.psc.edu/index.php/hpn-ssh we can do more work on this patch set. I don't get the money directly but it continues to support my work. What is HPN-SSH? HPN-SSH is a series of patches for OpenSSH to provide improved performance and functionality. The core of HPN-SSH is the implementation of a dynamic receive side buffer. By allowing this buffer to grow with the TCP receive buffer it's possible to attain significant throughput improvement - up to two orders of magnitude depending on the network path. Patch sets for each OpenSSH release will be found in the appropriate subfolder. Why does this work? OpenSSH implements SSHv2 - a multiplexed protocol that allows for multiple data connections across a single TCP stream. In order to provide necessary flow control for the individual channels that comprise this multiplexed connection it was necessary to, essentially, reimplement sliding windows on the receive side. This means that only a set amount of data can be outstanding (in transit) between the sender and receiver at any one time. The OpenSSH development team initially had this limited to 64KB (now 1024KB). Over low latency paths (and for interactive sessions) this is perfectly reasonable. However, for the transfer of large files this proves to be a significant bottleneck. This bottleneck was common to many TCP applications prior to the introduction of autotuning receive buffers in the TCP stack. HPN-SSH brings the current TCP receive buffer size up to the application layer and, by doing so, uses the network far more efficiently. The HPN-SSH team (Ben Bennet and Mike Tasota) also developed a multi-threaded variant of the AES-CTR cipher so as to allow multicored systems to distribute the burden of computing the keystream over multiple cores. This enhancement produces a cipher stream that is indistinguishable from the default AES-CTR cipher stream. The upshot of this being that it is backwards compliant with all existing AES-CTR implementations - no need to have the multithreaded variant on both sides of the connection. Recent work has also eliminated problems with using the multi-threaded AES-CTR cipher in forked connections (common with forwarded ports) and the sandboxed privsep process. For less sensitive data the team (primarily Micahel Stevens) also developed a method to switch to the NONE cipher after a fully cryptographically secure authentication. This method forces the stream to rekey itself after authentication and only proposes the NONE cipher. This patch may significantly improve performance for users whose processes were previously CPU bound. As the NONE cipher is essentially disallowed outside of debugging in OpenSSH users wishing to make use of the NONE cipher must have this patch installed on both sides of the connection. As an aside, the multi-threaded AES-CTR cipher and the NONE cipher exhibit similar throughput enhancement albeit, in the case of the AES-CTR cipher, of significantly higher CPU load. Currently the limiting performance factor, in terms of being CPU bound, is the HMAC cipher. HPN-SSH sees the HMAC cipher as being an intrinsically necessary component of SSH. While work is being conducted in order to enhance the performance of the HMAC processing there are no plans to eliminate it now or in the future. Lastly, the team also created patches to provide for enhanced server side logging and instantaneous throughput rate reporting in SCP. This current patch set, HPN14v20, passes all regression tests, provides a high level of security, and significantly increased performance with minimal fuss.