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?

  • 1
    You are dropping encryption and compression... let me think. Why don't you use FTP or SMB? – lajuette Oct 9 '10 at 7:19
  • 1
    No encryption sounds like no SSH really. Have you considered using another protocol altogether? – WhyNotHugo Jul 7 '13 at 21:18
  • 2
    @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

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.

  • Thanks for very informative answer and this really speed up the sshfs :) – Dzung Nguyen Jun 10 '12 at 13:57
  • 3
    Isn't it '-o cipher=arcfour' ? – asalamon74 Oct 3 '12 at 14:08
  • 1
    Will arcfour achieve 1Gbit speeds? – osgx Mar 15 '14 at 2:45
  • 1
    @osgx Yes, I would think so. See updated answer. – Dan D. Mar 15 '14 at 3:19
  • 4
    arcfour cipher deprecated and missing on most modern OpenSSH installations, You can use chacha20-poly1305@openssh.com instead. – Mesut Tasci Oct 10 '18 at 13:56

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

Source: http://pl.atyp.us/wordpress/index.php/2009/09/file-transfer-fun/

  • 2
    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
  • 3
    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
  • For a bit more security, your can also restrict the IP range with e.g. ,range=, to only allow one particular machine to connect. – Robin Dinse Jun 11 '18 at 13:11

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

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.

  • NFS would be a good choice – Jeremy L Aug 31 '09 at 13:00
  • The default seems to be "compression=no" anyway. – WhyNotHugo Jul 7 '13 at 21:18

since the answer from @endru fails on recent systems with

failed to resolve ubuntu@otherhost.lan:7777: Temporary failure in name resolution

and the example only allows one connection:

  • Server socat TCP4-LISTEN:7777,fork EXEC:/usr/lib/sftp-server

  • Client mkfifo /tmp/sshreturn;cat /tmp/sshreturn |sshfs -o slave,reconnect,cache=yes,kernel_cache,compression=no ubuntu@ /tmp/folder | socat STDIO tcp: > /tmp/sshreturn


I think compression is something that is really only quicker if the time to compress is compensated for by the time to transfer data. So compression on a slow connection is increasing speed up to maybe 6 times faster than without. Compression on a fast connection is not useful at all, as it drops speed due to compression delay on your or the host system. Some hosts don't accept compression at all, as they don't want to spend processor power on users.

I think this switch -o Ciphers=arcfour will increase the speed of encryption to nearly no encryption, and -o cache=yes -o kernel_cache -o large_reads -o compression=no may increase your speed a lot as it optimises sshfs a bit. Compression on low speed connections will speed up your transfer a lot if compression is possible; mostly it is. For example I do use it with a 2 Mbit/s down and 0,3 Mbit/s up connection, and it speeds up the transfer by about 3-5 minutes instead of 25-30 minutes for about 30 MByte.

  • In a way you are not giving better information than the accepted answer – yass May 7 '17 at 16:59
  • The accepted answer doesn't even mention compression. This answer may be slightly off-topic, but still has good advise. – Mantriur Mar 23 '19 at 14:19
  • gives fuse: unknown option large_reads on debian buster ` – Bash Stack Sep 27 '20 at 16:37
  • it's large_read not large-reads – Michael Goldshteyn Dec 14 '20 at 19:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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