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.)