Authors Top

If you have a few years of experience in the Linux ecosystem, and you’re interested in sharing that experience with the community, have a look at our Contribution Guidelines.

1. Introduction

File sharing is a common way for collaboration between hosts in a network. Also, it’s efficient because servers don’t have to be in the exact location to share storage.

In this tutorial, we’ll explore the SSHFS protocol and compare it to other network file systems.

2. What Is SSHFS?

The Secure SHell FileSystem or SSHFS establishes a connection using SFTP (Secure Shell File Transfer Protocol) to operate on files in a remote filesystem. This means we can interact with files on a different machine because they are served over an SSH connection on our local device.

SSHFS uses a FUSE implementation. FUSE stands for Filesystem in USErspace. It’s a software interface that allows users with limited privileges to create their filesystems without amending the kernel code. By using SFTP, we are sure that the transfer of files from a remote machine to a local machine is secure.

This is because SFTP encrypts the data in the stream. Additionally, SFTP uses host keys to verify a host’s identity.

2.1. SSHFS on Enterprise Systems

Most enterprise systems don’t provide support for the SSHFS package. When we try to install the SSHFS binary package, we’ll get an error message saying there’s no such package.

If we wish to use SSHFS in such systems, we should download the SSHFS binary from an EPEL repository. EPEL, which stands for Extra Packages for Enterprise Linux, is a special interest group (SIG) that provides additional packages for Linux distributions such as RHEL, CentOS, etc.

Here are a few examples of how we enable the EPEL repository in some Linux distributions:

$ sudo amazon-linux-extras install epel -y

This command needs to be executed on an Amazon Linux distribution. It won’t only install but also enable the EPEL repository. On the other hand, in CentOS 8, we’d need to install EPEL and PowerTools:

$ sudo sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-*
$ sudo sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-*
$ sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm -y
$ sudo dnf config-manager --set-enabled PowerTools

2.2. SSHFS on Ubuntu/Debian

Unlike RHEL and CentOS, Ubuntu does have the SSHFS binary package in its official repository. It has an advantage over other systems because we don’t need additional configurations. Let’s mount a filesystem using SSHFS on Ubuntu:

$ sudo apt-get update

Firstly, we need to update the package sources before installing SSHFS. It’s important to note that if we were using Linux distributions other than Linux/Debian, then the package name we’d have to install would be fuse-sshfs:

$ sudo apt install sshfs

We need an empty directory to mount the remote filesystem. Many Linux distributions include a /mnt directory that we can create sub-directories for this purpose. Let’s create a directory on our local machine where the remote directory will be mounted:

$ sudo mkdir /mnt/sshfs-mount

Subsequently, we can now mount the remote directory on our local system:

$ sudo sshfs -o allow_other,default_permissions [email protected]:/home/user1 /mnt/sshfs-mount
  • The -o flag indicates options
  • The allow_other option gives access to users that are not root
  • The default_permissions option enables permission checking by the kernel
  • user1 is the name of the user we access the remote host with
  • 172.62.13.42 is the IP address of the remote host
  • /home/user1 is the directory on the remote host that we’d like to mount
  • /mnt/sshfs-mount is the directory on our local host that we are mounting to

When we run this command, we’ll immediately be prompted for a password of user1 so that the user can log in to the remote server. The process of entering a password every time we mount a directory from this server can be tedious. We can eliminate this step by using SSH keys:

$ sudo sshfs -o allow_other,default_permissions,IdentityFile=~/.ssh/id_rsa [email protected]:/ /mnt/sshfs-mount 

If we use SSH authorization, we need to add an option called IdentityFile. This option allows us to specify a path to a local SSH key so that the remote directory is mounted immediately and without password prompts. The changes that we’ve made to the system won’t persist. To ensure that the remote filesystem remains mounted to our local machine even after rebooting, we need to edit the /etc/fstab file:

$ sudo nano /etc/fstab
...
[email protected]:/home/user1 /mnt/sshfs-mount fuse.sshfs noauto,x-systemd.automount,_netdev,reconnect,identityfile=~/.ssh/id_rsa,allow_other,default_permissions 0 0

3. Performance

SSHFS can be slow in performance because of data compression and encryption. It’s possible to increase the performance by decreasing the encryption strength. We can do this by adding options to our command when attempting to mount the directory:

$ sudo sshfs -o cache=yes,kernel_cache,large_read,Ciphers=arcfour,Compression=no,allow_other,default_permissions,IdentityFile=~/.ssh/id_rsa [email protected]:/home/user1 /mnt/sshfs-mount

These are the mount options we had to add to improve performance:

  • The cache=yes option turns on caching
  • The kernel_cache option allows the kernel to cache data
  • The large_read option allows larger reads which can assist with read performance
  • The Ciphers=arcfour option switches to a faster encryption algorithm, ‘ArcFour
  • The Compression=no option disables data compression

Some OpenSSH installations won’t have ARC4 since it’s deprecated. We’d need to configure an additional SSH cipher called [email protected]. We can check if this is configured by using the query option in the SSH command:

$ ssh -Q cipher-auth localhost
[email protected]
[email protected]
[email protected]

Since there is no way to disable encryption, we can only use a weaker encryption algorithm. It’s important to note that ArcFour (ARC4), also known as Rivest Cipher 4 (RC4), is a fast algorithm, but it’s considered insecure since it has many vulnerabilities. In our case, using ARC4 wouldn’t be a concern since both servers are in a LAN environment. In the event that both servers aren’t in a LAN, then using a weaker cipher is heavily discouraged.

If using ARC4 is still a problem on newer OpenSSH installations, then we can use the option -o Ciphers=aes128-ctr.

3.1. SSHFS vs. NFS

Similarly, the Network FileSystem or NFS allows remote hosts to access files over an Internet Protocol (IP) network like a remote host can access its files locally. NFS establishes a Transmission Control Protocol (TCP) connection over a network. Unlike SSHFS, NFS is not encrypted. We’d need to use a network authentication protocol such as Kerberos or a virtual private network (VPN) when transmitting sensitive information over the network.

Although NFS can be used over the internet, there needs to be additional configuration to have a secure data transfer, unlike SSHFS. Using plain-text NFS works best in a trusted environment such as a LAN. It’s also important to note that stale file hand errors are common with NFS. This is where the NFS server is not reflecting the new changes made by the NFS client and still has old versions of files in its export path. Normally, in this situation, we’d have to unmount and mount again. With SSHFS, we wouldn’t experience this.

Since SSHFS operates in the user space, we don’t need root privileges to configure it. Unfortunately, we can’t use NFS without the sudo command.

3.2. Disadvantages of SSHFS

The performance of SSHFS may decrease when reading and transferring larger files. Secondly, SSH uses a strong cipher. Therefore, the encryption process consumes a large CPU. If the server that we’re mounting to isn’t reachable, SSHFS will just wait on that stale connection. There needs to be manual intervention where the endpoint needs to be remounted.

Additionally, managing various SSH key pairs can be a tedious process, especially if many servers will be using SSHFS.

4. Conclusion

In this article, we looked at how we can enable file sharing between hosts using the SSHFS protocol. We discussed the underlying protocol of SSHFS and how we could set it up on a server. We explored how we could enhance the performance of SSHFS. Also, we compared it to different network file systems such as NFS and SMB. We delved into the disadvantages of the protocol as well.

Authors Bottom

If you have a few years of experience in the Linux ecosystem, and you’re interested in sharing that experience with the community, have a look at our Contribution Guidelines.

Comments are closed on this article!