How fast various ssh ciphers are

July 31, 2009

Periodically it surprises people to learn this, but ssh is not necessarily very fast (in the bandwidth sense). It's plenty fast for normal interactive use, but this speed issue can matter if you are making large transfers with scp, rsync, or the like; depending on your environment, ssh can go significantly slower than wire speed.

Ssh is slow because it has to encrypt and decrypt everything that goes over the wire, and this is a CPU-bound operation. How much time this takes depends on how fast the machines at each end are (the faster the better) and on which cipher ssh picks, because they vary significantly in speed.

Citing numbers is dangerous since yours are going to vary a lot, but here's some representative ones from Dell 2950s running 32-bit Ubuntu 8.04 with gigabit Ethernet:

  • the fastest cipher is arcfour, at a transfer rate of about 90 Mbytes/sec; arcfour128 and arcfour256 are about as fast within the probable margins for error of my testing.

    (This is still less than 80% of the full TCP/IP wire speed, and you can get gigabit wire speed on machines with much less CPU power than 2950s.)

  • the slowest cipher is 3des-cbc, at 19 Mbytes/sec.

  • aes128-cbc, the normal OpenSSH default cipher, is reasonably fast at 75 Mbytes/sec; this is the fastest non-arcfour speed.

That ssh's default cipher is among the fastest ones means that you can probably not worry about this unless you are transferring a lot of data and need it to go as fast as possible (in which case you should explicitly use arcfour).

(And of course all of this is relevant only if the rest of the system can read and write the data fast enough.)

All of this is with no compression. Since compression trades CPU usage for lower bandwidth, you should only turn it on if you're bandwidth-constrained to start with. (And on a multi-core machine you should consider doing the compression yourself, so that one core can be compressing while ssh is using the other core to do the ciphering.)

Comments on this page:

By rdump at 2009-07-31 11:31:02:

Patching to re-enable the 'none' cipher will get you closer to wire speed. Of course, the body of your transfer will then be in the clear, which is why it takes a patch rather than just a config option.

Even that isn't going to get you to maximum throughput, however. For more, you'll also want to change up the receive buffers used for congestion control. PSC has a HPN-SSH patch [1] that does this, among other things.

Running with enlarged receive buffers may show you more of a difference between arcfour128 and arcfour256.

The latest version of the PSC HPN-SSH patch [1] adds threading/multi-core support for offloading of the crypto work. This is better than enabling the 'none' cipher to send your data in the clear. Modern multi-core CPUs can keep up with GigE wire speeds using AES in additional threads.


From at 2009-07-31 15:10:39:

I can also recommend PSC's hpn-ssh patches. Using the multithreaded aes128-ctr cipher you'll easily reach GigE wire speeds. Once you move up to 10GbE and have any latency you'll need the buffer patches anyway.

Written on 31 July 2009.
« How we do custom NFS mount authorization on Solaris 10
Using SystemTap to trace the system calls of setuid programs on Linux »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Jul 31 02:00:15 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.