How can I disable encryption on openssh?
Solution 1:
Without recompiling anything, it cannot be done as far as I am aware. You can however switch to ARC4 or Blowfish which are preposterously fast on modern hardware.
The BEST performance (as far as clock cycles are concerned) increase you can get is with adding
compression no
You can do this by changing
ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
aes256-cbc,arcfour
to
ciphers arcfour,blowfish-cbc
If you want to squeeze some extra performance out at the risk of incompatibility you can change
macs hmac-md5,hmac-sha1,[email protected],
hmac-ripemd160,hmac-sha1-96,hmac-md5-96
to
macs hmac-md5-96
If you still think this is too much overhead, you could revert back to v1 or just do a standard VPN.
Solution 2:
Unless the client or the server is drastically underpowered, I'd highly doubt that it's the encryption that is causing your performance issues. I use an "-D 8080" ssh socks proxy regularly and have never noticed anything but a very slight slowdown.
One thing to check is to see what the latency is between your client and the server. If it's a very latent connection, you would surely see poor performance over the tunnel when using HTTP, while not seeing performance problems with FTP. Once an FTP transfer is in progress, latency doesn't really matter, but with HTTP, you're dealing with web pages that may have 50 or more individual HTTP handshakes that need to happen. High-latency connections will really slow this process down and will make browsing unbearable.
So anyway, the recommendations that Zephyr Pellerin made are sound. If you really think that it's encryption that's causing the problem them by all means, switch to a different cipher. I'd suggest looking into latency first, though, as that seems to be a much more likely candidate.
Solution 3:
This thread got me doing my own benchmarks and i found out that Performance varies not just by different cipher/MAC it also makes a difference what data you are sending, which CPU's are involved and how networking is set up.
So IMO the right thing to do is run your own tests and find the best settings for your situation.
If someone is interested, here are the results of my tests comparing an Intel E5506 driven Server with a Raspberry Pi:
--
-- Intel Xeon E5506(4 x 2.13 GHz), 50MB Random binary Data over localhost
--
cipher mac speed
---------------------------------------------------------------
aes192-cbc hmac-sha1 50MB/s
arcfour256 hmac-sha2-512 49.9MB/s
arcfour hmac-ripemd160 49.8MB/s
aes256-cbc hmac-sha1-96 49.7MB/s
aes128-cbc hmac-sha1-96 49.7MB/s
aes192-cbc hmac-sha1 48.9MB/s
arcfour [email protected] 48.8MB/s
aes256-cbc hmac-sha1-96 48.8MB/s
arcfour [email protected] 48.7MB/s
aes128-cbc hmac-sha1 48.4MB/s
--
-- Raspberry PI B+, 10MB Random binary over localhost
--
cipher mac speed
---------------------------------------------------------------
arcfour256 [email protected] 2.75MB/s
arcfour128 [email protected] 2.74MB/s
arcfour [email protected] 2.63MB/s
arcfour [email protected] 2.54MB/s
arcfour hmac-md5-96 2.36MB/s
arcfour128 hmac-md5 2.34MB/s
arcfour256 hmac-md5 2.34MB/s
arcfour256 [email protected] 2.33MB/s
arcfour256 hmac-md5-96 2.28MB/s
arcfour256 hmac-md5-96 2.22MB/s
But ony the 'top 10', the complete results can be found here.
Solution 4:
I was able to compile sshd/ssh with cipher 'none' with the help of this post: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=24559#58
It's a very old post, but you have to make 3 slight modifications to the source code file cipher.c. Then recompile the sshd/ssh code.
@@ -175,7 +175,7 @@
for ((p = strsep(&cp, CIPHER_SEP)); p && *p != '\0';
(p = strsep(&cp, CIPHER_SEP))) {
c = cipher_by_name(p);
- if (c == NULL || c->number != SSH_CIPHER_SSH2) {
+ if (c == NULL || (c->number != SSH_CIPHER_SSH2 && c->number != SSH_CIPHER_NONE)) {
debug("bad cipher %s [%s]", p, names);
xfree(ciphers);
return 0;
@@ -343,6 +343,7 @@
int evplen;
switch (c->number) {
+ case SSH_CIPHER_NONE:
case SSH_CIPHER_SSH2:
case SSH_CIPHER_DES:
case SSH_CIPHER_BLOWFISH:
@@ -377,6 +378,7 @@
int evplen = 0;
switch (c->number) {
+ case SSH_CIPHER_NONE:
case SSH_CIPHER_SSH2:
case SSH_CIPHER_DES:
case SSH_CIPHER_BLOWFISH:
Also, the none cipher will need to be added to your /etc/ssh/sshd_config
Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr,none
The links below will help you get ssh source for Debian and Ubuntu systems:
- https://askubuntu.com/a/345198/54228
- https://www.debian.org/doc/manuals/apt-howto/ch-sourcehandling.en.html
Credit to Dean Gaudet for being awesome
Solution 5:
According to this very nice blog post
http://blog.famzah.net/2010/06/11/openssh-ciphers-performance-benchmark/
I recommend to setup the following ciphers. Also make sure compression is off if you want the best performance on LAN. Please note this is possible security risk, use only on secure LAN (e.g. in home etc).
# cat ~/.ssh/config
Host 192.168.1.*
Compression no
Ciphers arcfour256,arcfour128,arcfour,blowfish-cbc,aes128-cbc,aes192-cbc,cast128-cbc,aes256-cbc
Modify the first line to list your own IPs in your LAN. You can also provide hostnames (separated by space). This gives you the best scp performance on LAN.