What influences SSH's bulk transfer speeds
A number of years ago I wrote How fast various ssh ciphers are because I was curious about just how fast you could do bulk SSH transfers and how to get them to go fast under various circumstances. Since then I have learned somewhat more about SSH speed and what controls what things you have available and can get.
To start with, my years ago entry was naively incomplete because SSH encryption has two components: it has both a cipher and a cryptographic hash used as the MAC. The choice of both of them can matter, especially if you're willing to deliberately weaken the MAC. As an example of how much of an impact this might make, in my testing on a Linux machine I could almost double SSH bandwidth by switching from the default MAC to 'email@example.com'.
(At the same time, no other MAC choice made much of a difference within a particular cipher, although hmac-sha1 was sometimes a bit faster than hmac-md5.)
Clients set the cipher list with
-c and the MAC with
-m, or with
MACs options in your SSH configuration file (either
a personal one or a global one). However, what the client wants to use
has to be both supported by the server and accepted by it; this is set
in the server's
MACs configuration options. The manpages
sshd_config on your system will hopefully
document both what your system supports at all and what it's set to
accept by default. Note that this is not necessarily the same thing;
I've seen systems where
sshd knows about ciphers that it will not
accept by default.
(Some modern versions of OpenSSH also report this information
ssh -Q <option>'; see the
ssh manpage for details.
Note that such lists are not necessarily reported in preference
At least some SSH clients will tell you what the server's list of acceptable ciphers (and MACs) if you tell the client to use options that the server doesn't support. If you wanted to, I suspect that you could write a program in some language with SSH protocol libraries that dumped all of this information for you for an arbitrary server (without the fuss of having to find a cipher and MAC that your client knew about but your server didn't accept).
ssh -v' will report the negotiated cipher and MAC that
are being used for the connection. Technically there are two sets
of them, one for the client to server and one for the server back
to the client, but I believe that under all but really exceptional
situations you'll use the same cipher and MAC in both directions.
Different Unix OSes may differ significantly in their support for both ciphers and MACs. In particular Solaris effectively forked a relatively old version of OpenSSH and so modern versions of Illumos (and Illumos distributions such as OmniOS) do not offer you anywhere near a modern list of choices here. How recent your distribution is will also matter; our Ubuntu 14.04 machines naturally offer us a lot more choice than our Ubuntu 10.04 ones.
PS: helpfully the latest OpenSSH manpages are online (cf), so the current
will tell you the latest set of ciphers and MACs supported by the
official OpenSSH and also show the current preference order. To
my interest it appears that OpenSSH now defaults to the very fast
One of SELinux's important limits
People occasionally push SELinux as the cure for security problems and look down on people who routinely disable it (as we do). I have some previously expressed views on this general attitude, but what I feel like pointing out today is that SELinux's security has some important intrinsic limits. One big one is that SELinux only acts at process boundaries.
By its nature, SELinux exists to stop a process (or a collection of them) from doing 'bad things' to the rest of the system and to the outside environment. But there are any number of dangerous exploits that do not cross a process's boundaries this way; the most infamous recent one is Heartbleed. SELinux can do nothing to stop these exploits because they happen entirely inside the process, in spheres fully outside its domain. SELinux can only act if the exploit seeks to exfiltrate data (or influence the outside world) through some new channel that the process does not normally use, and in many cases the exploit doesn't need to do that (and often doesn't bother).
Or in short, SELinux cannot stop your web server or your web browser from getting compromised, only from doing new stuff afterwards. Sending all of the secrets that your browser or server already has access to to someone in the outside world? There's nothing SELinux can do about that (assuming that the attacker is competent). This is a large and damaging territory that SELinux doesn't help with.
(Yes, yes, privilege separation. There are a number of ways in which this is the mathematical security answer instead of the real one, including that most network related programs today are not privilege separated. Chrome exploits also have demonstrated that privilege separation is very hard to make leak-proof.)