Linda Walsh wrote:

> Sounds like it is unlikely to provide an "easy" way to remove
> the data encryption from the equation.

Why do you say that?

> I'm not clear if the HPN-SSH "patch" is a patch over Ossh or
> a different, but depending on how much change HPN-SSH adds, I might
> be benchmarking something that is unrepresentative of Ossh.

Its a patch against OpenSSH with support for all of the recent releases.
It's primary goal is to open up the receive window limitation that
imposed by the multiplexing. If the BDP of your path is greater than 64k
in the case of 4.6 (or less) or around 1.25MB for 4.7 it can increase
your throughput assuming the network and end hosts are well tuned.

This performance increase is often large enough to make CPU overhead the
limiting bottleneck - which is why we incorporated the NONE cipher

>> What are you typically seeing for your transfer rates? What cipher/MAC
>> combination are you using and what version of OpenSSL? Also, what
>> version of OpenSSH?

> ----
> Most are under 12MB/s (which, I know, sounds like very good
> 100Mbs performance -- cept that I'm expecting Gigabit performance.
> Interfaces are running at 1G verified w/"ethtool" and "lights on
> the switches involved".

I'm not sure if you mentioned this or not but are you pegging your CPU?
As an aside, using a multicore machine won't help you much as SSH is
limited to using one core.

Anyway, diagnosing network performance problems can be a complicated
proceedure because any number of failures all manifest as the same
problem - slow throughput. You should start by making sure that you your
TCP receive buffers are large enough to accommodate the throughput you
are trying to achieve. They need to be at least the same as the
bandwidth delay product (bandwidth and the narrowest point multiplied by
the round trip time). If they aren't then increase them using the
appropriate methods. You can find out more about this from

> I want to test it both ways. How can I easily tell what is due to
> my network's speed, the SSH protocol, or even the implementation?

Start by doing baseline measurements of the network speed. If you
haven't looked at it yet Iperf is your best solution for that. Since it
doesn't rely on pipes, the filesystem, or anything like that its your
lightest weight option. Since it can also run in UDP mode it can even
give you information on any unexpected packet loss. Then rerun the tests
using a sample file to see how much of a bottleneck disk I/O is. At that
point you can determine how much of an impact the application is having.

> How is it a security hole? I am proposing that it must be explicitly enabled in sshd_config (allowed on a per-host basis, as it is likely only
> something someone would use with certain "safe" (likely internal-private)
> networks. Also, in order to make certain it comes from a valid machine,
> session authentication should be done "as normal". Only after
> authentication would null be allowed.

And pretty much that's all been implemented in the HPN-SSH patch. You
can't embed the NoneEnabled directive in a Match block at this time. It
may or may not be possible but its a good idea and something I'll be
looking into over the next few weeks.

> That should spell it out very clearly enough to prevent
> "accidents". What security holes would I be missing?

If you enable NONE switching for interactive data you do actually open a
security hole. People *should* have the expectation that anything they
type into a secure shell should be, well, secure. I do not think that
necessarily applies to bulk data transfer though - with proper
safeguards in place.

But really, I'm not entirely sure what you want. If you *just* want to
benchmark things with and without encryption its not that hard to hack
the none cipher back into the cipher lists. If you want a more general
solution that can be used in a production environment then you should
probably just use the HPN-SSH patch.
openssh-unix-dev mailing list