This is buggy. We had it deployed on a small number of servers , basically our backup server and a few servers that needed to backup to the backup server.
We would run into problems with standard SSH connecting to HPN-SSH these bugs were confusing and difficult to debug until we realized that the difference was HPN-SSH and reverted to standard SSH all problems went away quite quickly.
What is the license of these patches? There doesn’t seem to be anything on the website, nor in all of the patches available for download.
Are there other reasons apart from licensing why this has not been merged into mainline OpenSSH?
Edit: At least the multithreaded AES-CTR cipher has license information in the header, which seems to be standard BSD. It stands to reason that the rest of the patches have the same license?
The Sourceforge page says the project is BSD-licensed. But if the license isn't applied to all the files, and no other root-directory file says that all the files contained within are licensed as such, i'm pretty sure you're not legally covered. If I were a distro I wouldn't include these without asking the authors to put a license declaration covering all the patch changes at the beginning of the file.
I am the author. Honestly, I initially released them without any sort of license - entirely free from any sort of license restriction. People don't seem to understand that so I said they have a BSD license on them. Personally, the license is kind of a moot point (in my view) as the once you patch OpenSSH with them the code is subsumed by the license used by OpenSSH. The only but that might be up in the air is the aes-ctr cipher. In any case I'm trying to find the cycles to include the license and then incorporate it into all of the bits and then build new packages for sourceforge. In the mean time, take my word (as the author) regarding the license. It's free and open. Just keep the attribution. Send me mail at hpn-ssh@psc.edu for identity confirmation if you like.
I wrote an email to the HPC-SSH team and got the following response:
> I'm at a conference this week so I'll make the license more clear next week in the repo. Basically, it's a very lax bsd style license. Maintain attribution and you can do as you like with it. However, please understand that when incorporated into OpenSSH the OpenSSH license takes precedence.
> Also out had been submitted some years ago but there was resistance to the patch for non technical reasons so I've home my own way on it.
In addition to host and network tuning guides they also have a list of data transfer tools, including HPN-patched sftp and scp, but they recommend GridFTP because it supports parallel streams: http://fasterdata.es.net/data-transfer-tools/gridftp/
I've been using this a lot recently - https://github.com/LabAdvComp/UDR - A UDT wrapper around rsync - No need to patch anything, therefore no maintenance woe
After finding that using scp to copy stuff over my local network (and before finding out about hpn-ssh) I wrote this icky script to get better performance copying moving stuff around: https://github.com/toofar/fcp
It just wraps ssh+netcat+tar. The ssh connection is just used to setup the netcat (actually nc) connection like in mosh.
It doesn't have much dependencies (although it can use pv if installed on the local machine) and so should work on most platforms (didn't work on android last I checked, but I think I know why). It's a pretty ugly script (in particular errors are not propagated back to the terminal and backgrounding pv can lead to offset output) but it works and can even use scp's bash_completion script for completion on a remote filesystem.
The need to use netcat is that it is faster. It gets better throughput in the presence of plentiful bandwidth. The whole point was to avoid using ssh for bulk transport.
Gentoo has this as a USE flag for openssh and is enabled by default. Be aware that the multithreaded AES-CTR patch has compatibility conflicts with some libssh versions and possibly other implementations. XBMC and Synology in particular have both been unable to connect to servers using that patch.
I wonder what the current performance difference is to OpenSSH6.1+? I think those graphs they have might be very old, and there's been a lot of improvements in the core OpenSSH code since then.
Native OpenSSH performance seems quite good these days- are you certain this is still necessary? Either the SSH client and server I used had this patch, or the windowing code in SSH was removed/modified.
The main problem is that the internal buffer size for OpenSSH is limited to 2MB (actually it's closer to 1.25MB in real world terms). This is pretty good for a lot of home users. However, HPN-SSH was written for the HPC communuity where we have have BDPs of well more than that (8MB is not uncommon). So if you have a BDP of more than 2MB HPN-SSH is still going to be a win for you.
2 questions:
1) would this work with mosh? 2) lzo/lz4 has lower latency then zip, is there an ssh patch supporting this and would it be noticable in a 2k4 scenario?
mosh uses a completely different protocol (over UDP), and I think the aim of these patches is to improve throughput, not latency, of SSH. In a high performance situation you probably have high bandwidth, and then it's better to disable any compression. Compression only makes sense when you have limited bandwidth and sufficient CPU power.
Not likely. The OpenSSH team is very conservative, and RedHat isn't likely to make such an invasive change into a core utility.
PSC has been maintaining these patches for a long time. I'm pretty sure I was using this nearly 10 years ago. If you have a need for this, it's not hard to build it yourself.
Ah, found the initial release date: July 7, 2004; yeah 10 years.
