Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am a very frequent user of sshfs for mounting various disks over the network. I do however have a very small machine (with an atom processor) from which I need to mount a directory using sshfs.

Is it possible to disable all compression, and perhaps even also encryption when mounting using sshfs, as to limit the cpu usage on the machine from which the directory is mounted?

share|improve this question
You are dropping encryption and compression... let me think. Why don't you use FTP or SMB? – lajuette Oct 9 '10 at 7:19
No encryption sounds like no SSH really. Have you considered using another protocol altogether? – Hugo Jul 7 '13 at 21:18
@lajuette: As Dan D. states below, ssh authentication will still be encrypted, so no passwords or keys in plaintext. Also, do you know any protocol that is as readily available as ssh where I can mount remote folders as easily as I can with sshfs? – Bjarke Freund-Hansen Mar 24 '14 at 7:48
@lajuette I want the same sort of thing and my reason is that I need something my quarantined Win98 and WinXP retro-gaming machines can use to pull files off my Linux desktop PC and, of the available options, SSH via WinSCP Just Works™ through my whitelist quarantine firewall while FTP and SMB won't work, no matter how hard I try to open the right ports. (And WebDAV can apparently only be served by Apache, which is too complicated to chroot.) – ssokolow Nov 3 '15 at 0:20
Oh, plus, AES gives me 27Mbit throughput on the Athlon64 3200+, maxing out the CPU, while RC4 doubles that, so no encryption should get even closer to maxing out the 100Mbit NIC on the WinXP side. (Given that the rotating rust drives currently installed on both ends of the copy operations in question max out at around 200Mbit when SMB is used with contiguous files to remove the need for seeking.) – ssokolow Nov 3 '15 at 1:28
up vote 25 down vote accepted

Although the high performance ssh adds a none cipher, the arcfour cipher is nearly as fast and is included standard.

Use: -o Ciphers=arcfour

I've been using this over the local network and I get about 85% of 100Mbps Ethernet or about 10.625MB/s

(In response vava's answer, sshfs would still be what it is even when ssh's encryption is off as the authentication protocol would still be active without which you might as well be using telnet.)

Note for @osgx I recently found OpenSSL: Cipher Selection which includes the following graph:

enter image description here

The following is the results section from that page. The graph and the results are questionable as they don't state how the benchmark was done and on what hardware but I think that they aren't that far off.

100,000 Kbyte/s is my threshold for acceptable performance. This represents 1 CPU core (of 8 in my case) running at 100% utilization to transfer 780Mbit/s of data (which is a reasonable saturation point for a gigabit Ethernet link).

RC4 is the fastest cipher, if you are using a processor which does not support AESNI.

AES-128 is the next fastest cipher, and much faster than RC4 if you have AESNI support. It’s about 54% slower if you don’t. AES-256 is slower still, and unless explicitly configured otherwise, any browser that supports AES-128 will also support AES-256.

What has been quoted above clearly shows that arcfour (and also AES with AESNI) can saturate a Gigabit link on a modern machine.

If you don't need encryption, the none cipher from hpn-ssh is even faster but you would only need it if you need to saturate a link with several times the bandwidth of a Gigabit link or if you need reduced CPU usage.

share|improve this answer
Thanks for very informative answer and this really speed up the sshfs :) – nXqd Jun 10 '12 at 13:57
Isn't it '-o cipher=arcfour' ? – asalamon74 Oct 3 '12 at 14:08
@asalamon74 No, it is not. From man ssh_config, "Ciphers: Specifies the ciphers allowed for protocol version 2 in order of preference." – Dan D. Oct 6 '12 at 5:20
Will arcfour achieve 1Gbit speeds? – osgx Mar 15 '14 at 2:45
@osgx Yes, I would think so. See updated answer. – Dan D. Mar 15 '14 at 3:19

For sftp with no encryption, use sshfs + socat

On the server side run

socat TCP4-LISTEN:7777 EXEC:/usr/lib/sftp-server

And on the client side

sshfs -o directport=7777 remote:/dir /local/dir


share|improve this answer
While this may theoretically solve the problem, it would be preferred to summarize the link contents, and provide the link as reference – Canadian Luke Nov 30 '12 at 6:15
By default, socat TCP-LISTEN listens on all interfaces. To limit to one specific network interface (e.g., localhost), use the ,bind= option. To allow multiple connections to the server, add the ,fork option. Making a read-only server? Add -R to the EXEC command. In the end, it will look like this: socat TCP-LISTEN:7777,fork,bind= EXEC:'/usr/lib/sftp-server -R' (on Arch Linux, I had to use /usr/lib/ssh/sftp-server instead). – Lekensteyn Mar 22 '14 at 15:51

There is no way to disable encryption - this is ssh after all. And it looks like compression is disabled by default as you have to request it with the -C switch.

But you may want to check your ~/.ssh/config file for settings regarding compression. If you add the following lines at the top of that file, compression should be disabled:

Host *
    Compression no
share|improve this answer

You can mount with -o compression=no to turn the compression off. It is not possible to turn encryption off, wouldn't be sshfs after that :) If it is slow I suggest to use other way to mount a directory, like through samba, nfs or ftp.

share|improve this answer
NFS would be a good choice – Nerdling Aug 31 '09 at 13:00
The default seems to be "compression=no" anyway. – Hugo Jul 7 '13 at 21:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.