/j-hpn-ssh

j-hpn-ssh: A development fork of the Pittsburgh Super-computing Center's High Performance SSH implementation.

Primary LanguageCOtherNOASSERTION

J-HPN-SSH

NOTE: This is discontinued due to being mostly obsoleted and PQ-crypto now in mainline. HPN patches still maintained upstream @rapier1

High-Performance SSH

License LocCount GitHubCodeSize TickgitTODOs

CodebeatBadge CodacyBadge DeepSourceActive DeepSourceResolved

What is HPN-SSH?

HPN-SSH is a series of modifications to OpenSSH, the predominant implementation of the SSH protocol. It was originally developed to address performance issues when using SSH on high speed long distance networks (also known as Long Fat Networks or LFN's).

By taking advantage of automatically optimized receive buffers, HPN-SSH can improve performance dramatically on these paths. Other advances include optionally disabling encryption after authentication to transport non-sensitive bulk data, modifying the AES-CTR cipher to use multiple CPU cores, more detailed connection logging, and peak throughput value calculations shown in the SCP progress bar.

What is J-HPN-SSH?

J-HPN-SSH is an experimental development fork of HPN-SSH. It is not associated in any way with the upstream project. It currently incorporates select changes from the IBM, Red Hat, and Debian SSH distributions, various other patches to keep up to date with upstream OpenSSH-portable, and various adjustments to HPN-SSH's buffer sizing and congestion control.

Availability

J-HPN-SSH future plans

Besides staying up-to-date with OpenSSH-portable, currently, plans include additional tuning, including assembly-level optimization of existing code, as well as the addition of new cryptographic functionality, likely to include new post-quantum algorithms, enhanced hashing and key exchange mechanisms, and new key systems, such as SHAKE, SHA-3, BLAKE-3, Schnorrkel/Ristretto-Sr25519, Intermac, Ristretto255/Curve25519-Dalek, X448-Goldilocks, E-5321, Kyber, SIDH, Dilithium, SPHINCS-SHAKE256, SPHINCS+, CSIDH, etc.

Experiments that are successful will be made available to the upstream HPN-SSH project. No GPL or similarly licensed code will be incorporated, and all newly added code will be licensed under the same terms and conditions of the current OpenSSH-portable and HPN-SSH distributions.

Security information

This software may contain bugs, including critical security vulnerabilities, despite the author's best efforts.

Warranty (or lack thereof)

BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING, THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS", WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.

SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR, OR CORRECTION. IN NO EVENT, UNLESS REQUIRED BY APPLICABLE LAW, OR AGREED TO IN WRITING, WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE, OR INABILITY TO USE, THE PROGRAM, INCLUDING BUT NOT LIMITED TO, LOSS OF DATA, OR DATA BEING RENDERED INACCURATE, OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES, OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS, EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

License

See the LICENSE file for full details.

Operational Details

SCP and the underlying SSH-2 protocol implementation in OpenSSH is network performance limited by statically defined internal flow control buffers. These buffers often end up acting as a bottleneck for network throughput of SCP, especially on long and high bandwidth network links.

Modifications to the SSH code to allow these buffers to be defined at run-time eliminate the bottleneck.

HPN-SSH is fully interoperable with other SSH servers and clients. In addition, HPN-SSH clients will be able to download faster, even from non HPN-SSH servers, and HPN-SSH servers will be able to receive uploads faster, even from non HPN-SSH clients, as long as the host receiving the data has a properly tuned TCP/IP stack.

The amount of improvement any specific user will see is dependent on a number of factors. Transfer rates cannot exceed the capacity of the network, nor the throughput of I/O subsystems, including the disk and memory speed. The improvement will also be highly influenced by the capacity of the processor to handle encryption (and decryption).

Performance gap

With most high-bandwidth connections, there is a performance gap between what SSH is capable of, and what the network link has the capacity to do. This gap, in most situations, is the direct cause of undersized receive buffers in SSH's congestion control mechanism.

Normal SSH SCP vs. (J-)HPN-SSH SCP performance

HPN-SSH offers significantly enhanced SCP throughput performance. Increasing the size of the SSH channel receive buffers has been shown to improve SCP throughput by as much as 1,000%.

Possible HPN-SSH bug

If you are experiencing disconnects due to a failure in buffer_append_space, you should try using -oHPNBufferSize=16384 to restrict the growth of this buffer.

J-HPN-SSH-specific notes

This is the "standard" configuration, primarily tested on Fedora 33

make clean; make distclean; export LD_LIBRARY_PATH=/opt/hpnssl/lib && autoreconf -vfi
./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu \
--prefix=/opt/jhpnssh --with-default-pkcs11-provider=yes --with-ldns \
--with-default-path=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin \
--with-superuser-path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
--with-privsep-path=/var/empty/sshd --without-zlib-version-check --with-ssl-engine \
--with-ipaddr-display --with-pie=yes --with-systemd --with-security-key-builtin=yes \
--with-pam --with-audit=linux --with-sandbox=seccomp_filter --with-libedit --with-4in6 \
--with-ldns CFLAGS="-I/opt/hpnssl/include" --with-ldflags="-L/opt/hpnssl/lib" && \
make -j "${CPUS:-1}" && sudo make install
  • /opt/hpnssl contains the latest stable 1.1.1 LTS OpenSSL release.

    • Build with defaults: ./config --prefix=/opt/hpnssl && make -j "${CPUS:-1}" && sudo make install.

      • This is due to some bugs/errors the J-HPN-SSH maintainer is working to track down on Red Hat/Fedora systems. Also, on these systems, Kerberos 5 and TCP-Wrappers should not be enabled, as they are almost always linked to the system OpenSSL library. Linking to multiple versions of OpenSSL this way is not a supported configuration.

        • Compilation with OpenSSL 3-alpha is known to work (and periodically tested), however, care must be taken to avoid OpenSSL version conflicts when linking.
    • TCP-Wrappers support has been deprecated as of RHEL 8 and Fedora 23; the tcp_wrappers-devel package that provides the necessary headers is no longer made available; the standard Red Hat SSH does not include any support for TCP-Wrappers. If you want to enable TCP-Wrappers on these systems, you will need to compile and install TCP-Wrappers from source code, preferably, the most recently released Red Hat SRPM's, which were distributed with RHEL 7.

      • If you see any runtime errors such as debug1: EVP_KDF_derive(ctx, key, key_len) != 1 [preauth] or ssh_dispatch_run_fatal: ... error in libcrypto [preauth], then you are likely affected by this bug, and should build a separate OpenSSL library for J-HPN-SSH to use, as described above.
  • It is highly recommend to use the ldns libraries, as they provide well tested, first-class DNSSEC support. Upstream and third-party patches for supporting DNSSEC without ldns have been merged, however, this configuration is currently not well tested; feedback here would be appreciated.

  • Currently, SELinux support is known to be broken, but should be fixed soon.

Upstream HPN-SSH Future Plans

  • Automatic resumption of failed transfers
  • AES-NI hardware acceleration for the AES-CTR cipher
  • Parallelization of the ChaCha-20 cipher
  • In-line network telemetry
  • Pipelined HMAC generation
  • Enhanced distribution packaging

HPN-SSH Original Authors

  • Chris Rapier
  • Michael Stevens
  • Benjamin Bennett
  • Mike Tasota

HPN-SSH Upstream Homepage

OpenSSH Upstream Homepage