[blasdel]

Aw man, I was hoping this would be a passthrough mode for the transport.

Sometimes I'd like to have secure authentication but otherwise have no encryption — the overhead is way too high on slower boxes when you have a good amount of bandwidth available. One classic case I'd run into is using a nice old Sparc workstation as a remote X terminal to a fast new box: if I used SSH to forward the X session its process would regularly spike the local CPU, so I would end up just using a completely insecure X server instead.

It can be too slow even on decently fast boxes when you have gigabits of bandwidth available — I'd just end up piping tar through netcat to avoid the overhead.

[sketerpot]

I wonder how much of this is just because you're using a slow encryption function. On my (quite fast) machine, the default 128-bit AES encryption can handle a little under 800 Mbit/s. Meanwhile, Threefish-512 can encrypt at 4 Gbit/s on the same machine, with what we lightheartedly hope is an equal or greater amount of security. And if you use CTR mode for block chaining, you can parallelize it among however many cores you have, for several times speedup -- my quad-core machine could manage 16 Gbit/s with Threefish-512 in CTR mode, which is really quite zippy.

What I'm saying is, faster transfers should be possible. And they probably already are, if you're willing to find out how to tweak the OpenSSH settings. Maybe.

[fhars]

You want the HPN-SSH cipher-none patch: http://www.psc.edu/networking/projects/hpn-ssh/ Although even the HPN-SSH project recommentd using MT-AES-CTR on multicore machines to get encryption and saturate a 1GBit link.