Your choice of cipher is unlikely to make a difference on the performance of SSH. In most cases, your CPU can encrypt/decrypt faster than your network can keep up. In most situations, network bandwidth seems to be the limiting factor.
Therefore, I suggest that you just leave SSH at its defaults. They're fine. The defaults are reasonably secure, and tweaking with the defaults is not likely to provide noticeably better performance.
If you really want to play around with parameters, you can check out SSH's use of compression. By default, all data will be compressed before sending it over the encrypted channel. You can adjust the compression level with
ssh -o 'CompressionLevel 6' (replace 6 with any number from 1-9, 1 is fastest, 9 is slowest). However, personally, I haven't found significant gains from changing the compression level. Also, if you are transferring a file that is already compressed with scp, you can turn off compression with
scp -o 'Compression no' .... In some cases (where you have a very fast network and a slow CPU), this might help some, though in my experience I haven't found it makes a big enough difference to be worth worrying about.
Of the ciphers supported on my OpenSSH client, all of the following should provide strong security:
You should not use
des, as it provides weaker security (
3des is fine). I'm not sure about
arcfour, as I haven't kept up with the literature in this area, but they seem riskier to me than the others. Of the message authentication code (MAC) algorithms supported on my OpenSSH client, all of the following should provide strong security:
Of the HostKeyAlgorithms supported on my OpenSSH client, all supported options (
ssh-dss) are fine and should provide strong security, as long as you choose a key of sufficient length. I'm not familiar with the KexAlgorithms option.
In short, basically all of the cryptographic options provided should be safe enough, except don't use plain
des and it might be best to avoid