24

I'm having performance problems using openssh (server) and putty (client) combination to use a remote webproxy. I'd like to disable encryption and test the results to see if it makes a difference. How can i do that? Is there anything i can modify in the sshd_config. I'm very new to openssh.

Any other ideas would be appreciated.

I've basically set my IE to use 127.0.0.1 socks as a proxy. I connect my putty to my openssh server at home and voila - I'm able to browse the internet through that. However, it's incredibly slow even though I know I have a fast connection to my home (ftp for example works at above 50Kbytes/sec.

Jakuje
  • 9,145
  • 2
  • 40
  • 44
  • 3
    It's a pity the rot13 patch (http://www.miranda.org/~jkominek/rot13/) never caught on... – Kenster Feb 25 '10 at 20:50
  • 5
    I highly doubt that the encryption used by SSH is the cause for your slow connection as long as your SSH server is not running on a digital wrist watch from 1980. – joschi Feb 26 '10 at 10:49

8 Answers8

18

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,umac-64@openssh.com,
      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.

blueyed
  • 723
  • 8
  • 13
zetavolt
  • 1,352
  • 1
  • 8
  • 12
  • 3
    If your OpenSSH installation (on both ends) is complied with support for the "none" cypher, you can also specify that, but that defeats the whole purpose of *secure* shell. – voretaq7 Feb 25 '10 at 18:57
  • 1
    For the C-inclined among us, you can add in *{ "none", SSH_CIPHER_NONE, 8, 0, 0, EVP_enc_null }* to cipher.c in the cipher array. – zetavolt Feb 25 '10 at 19:45
  • 6
    I could also point out, You can use something like socat (http://www.dest-unreach.org/socat/) to do the same thing AND avoid all the SSH protocol overhead. – zetavolt Feb 25 '10 at 19:47
  • I think umac-64 is the fastest of those mac algorithms. – President James K. Polk Feb 27 '10 at 20:36
  • 96 bit MD5 is incredibly quick in any case. – zetavolt Feb 28 '10 at 16:46
  • Thanks Zephyr! After some struggling I got socat working... using that now. ssh is still simpler to set up and present by default on my systems, but having a alternative is always useful) – Marius Feb 25 '11 at 15:43
  • If you only want this for some connections you can set it via command line flags: `ssh -o compression=no -o ciphers=arcfour,blowfish-cbc -o macs=hmac-md5-96` or short version: `ssh -m hmac-md5-96 -c arcfour,blowfish-cbc` – Florian Fida Feb 04 '15 at 19:22
  • 1
    It is contrary the spirit of Unix that ssh forces encryption down our throats by not allowing a none protocol. It is not only the communication overhead, it is also the time wasted by handling keys in a perfectly secure local cabled network with a dozen Raspberry pi's. – Albert van der Horst Feb 08 '21 at 16:47
6

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.

EEAA
  • 108,414
  • 18
  • 172
  • 242
  • +1 for this ... the problems highly unlikely to be the encryption and is more than likely going to be the connection to your host at home in the first place. – DaveG Feb 25 '10 at 20:02
  • 22
    I wish people would stop saying that you do not need to do this and get into a long discussions about the benefits and downfalls of encryption overhead (if or if not any), and just try and answer the question. I do not see a reason to add redundant encryption for my local task on my local machine for which I need at least authentication, but working from localhost to localhost is really not requiring encryption. – Marius Feb 24 '11 at 17:48
  • 6
    Not true, try to copy a large file using scp on a gig-ethernet. Intel iCore 5 load is 80 %. – lzap Jan 09 '12 at 15:56
  • 1
    @Izap> There is more to it than just encryption though. Transferring a large file using `ftp` (without ssl) also gets me a 20 to 40%-ish cpu load. I blame cheap gig-ethernet requiring too much attention from the cpu. – spectras Sep 21 '17 at 00:47
  • When you use SSH for ZFS send/receive, CPU is bottleneck ;) – Xdg Nov 21 '17 at 10:52
6

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                     hmac-ripemd160@openssh.com 48.8MB/s
aes256-cbc                  hmac-sha1-96               48.8MB/s
arcfour                     hmac-ripemd160@openssh.com 48.7MB/s
aes128-cbc                  hmac-sha1                  48.4MB/s


--
-- Raspberry PI B+, 10MB Random binary over localhost
--

cipher                      mac                        speed
---------------------------------------------------------------
arcfour256                  umac-64@openssh.com        2.75MB/s
arcfour128                  umac-64@openssh.com        2.74MB/s
arcfour                     umac-64@openssh.com        2.63MB/s
arcfour                     umac-64@openssh.com        2.54MB/s
arcfour                     hmac-md5-96                2.36MB/s
arcfour128                  hmac-md5                   2.34MB/s
arcfour256                  hmac-md5                   2.34MB/s
arcfour256                  umac-64@openssh.com        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.

Florian Fida
  • 307
  • 3
  • 13
  • 1
    results without the 'none' cipher are incomplete for this topic. I have many pogoplugv4 (800Mhz arm version = slow) and they often peg the cpu with ssh. this is why people seek the none cipher. ssh/sshd cpu usage at 100% means its not a network problem! i hope i remember to come back and post the cipher=none results... – user2420786 Apr 14 '15 at 12:19
  • Do you have the script you were using to generate this data? I would be pretty interested in the performance of the current ciphers (`chacha20-poly1305@openssh.com`) on today hardware. – Jakuje Sep 21 '16 at 14:34
  • Its all inside the gist: https://gist.github.com/piccaso/b74209cc3396587892b4/ – Florian Fida Sep 22 '16 at 21:30
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,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,none

The links below will help you get ssh source for Debian and Ubuntu systems:

Credit to Dean Gaudet for being awesome

Community
  • 1
Sepero
  • 159
  • 1
  • 5
2

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.

lzap
  • 2,704
  • 2
  • 22
  • 22
1

IF you want to try a completely unencrypted and uncompressed tunnel you could try using something like rinetd to forward the data instead of SSH. This would iliminate the SSH extras while stil offering a plain binary-safe tunnel for TCP connections.

When you say that you have a fast connection at home, are you sure that it is fast in both directions? Many home connections are very asymetric (my home ADSL for instance is ~11Mit downstream and ~1.5Mbit upstream and many are worse than that, some I can quote from friends/family connections: 7M/0.4M, 19M/1.3M, 20M/0.75M, ...). Remeber that if you are using home as a proxy the data has to go through your link both ways so will move at best at the slowest of your downstream and upstream speeds and you have a chunk of extra latency to factor in too. Also your ISP might deliberately throttle upstream communication (either blanket, or selectively so that things like email and selected popular web sites are not affected) as a way to discourage people running servers/proxies off their home links, though this is relatively rare.

David Spillett
  • 22,534
  • 42
  • 66
0

I've just done extensive testing on this, and the cipher suite that yielded the highest throughput was aes-128-ctr with umac64 MAC. On a 4-core 3.4GHz machine I saw almost 900MBytes/sec through localhost (to eliminate network bottlenecks for the sake of benchmarking)

If you really need that much performance, you want the newest SSH, and possibly the HPN-SSH patches.

Marcin
  • 2,281
  • 1
  • 16
  • 14
0

This is one client side SSH option I used for SSH connection to low-end devices:

ssh -c none -m hmac-md5-96 -oKexAlgorithms=curve25519-sha256@libssh.org ....

None cipher is natively supported in recent OpenSSH versions. However, since 7.6, OpenSSH removed SSHv1 support and labelled "none" cipher for internal usage.

#define CFLAG_NONE      (1<<3)
#define CFLAG_INTERNAL      CFLAG_NONE /* Don't use "none" for packets */

Then you need patching and recompiling for both server and client side.

#define CFLAG_INTERNAL      0
V.E.O
  • 101