Working on remote file systems is made simpler with the user-space-defined file system of SSHFS.

Whether you're on a local LAN or in a remote, distant location, chances are you're using SSH to gain remote access to your Linux servers. With SSH access, tools like scp (secure copy) make it possible to transfer files to and from machines but sometimes with a price of repetitive typing of arguments and commands. Other options such as Samba and NFS can be more difficult to configure and use, with firewalls and diverse network configurations in place. With the tool SSHFS, as long as you have SSH access, remote file systems can be mounted locally, where they can be viewed and used with local tools and scripts.

How SSHFS Works

The SSHFS protocol has actually been around for quite some time, although the latest implementation is a re-write done by Miklos Szeredi. SSHFS in its current form uses the FUSE (Filesystem in Userspace) file system. Probably not coincidentally, the author of FUSE is also Miklos Szeredi. The advantage in using FUSE is that it gives the non-privileged user the ability to create and edit file systems within the kernel space. FUSE does so by providing a bridge between the user space and the kernel, making it very simple to implement as a kernel module.

The transport layer that SSHFS uses after the file system is mounted is actually a well-known protocol, sftp. Security is presented by SSH itself. Since SSH access is required, you won't be allowed to mount anything from the remote server without proper authentication. Like everything else security-related, SSH can be configured very securely or very loosely. In a trusted LAN situation, password authentication might be secure and proper, but the best method is to use SSH keys across remote systems.

Installation and Setup

The beauty in SSHFS is the lack of configurations on both the local and the remote client. Most common Linux systems have the packages required that are installable through their own package manager. In my environment, RHEL/CentOS packages are fuse-sshfs and fuse-libs. Whatever system you're using, use the package manager to search for "sshfs" packages and you should find what you need. In RHEL/CentOS, use yum to load the packages. All dependencies not already on the system will be installed as well. Remember to install the packages on both the remote host and the local client.

# yum install fuse-sshfs

If you can't install SSHFS and FUSE, you can download the sources and compile the packages to install them manually. Downloads can be found here at the FUSE Web site.

Next, from the local client you're going to use to mount the remote file systems, add your normal user to the fuse group that the package installation created. If you run everything from the root account, everything will just work; however, running them from a non-privileged account requires some permissions. As root, add your user to the group and also create a mount point that is owned by your user.

# usermod -a -G fuse username

# mkdir /media/sshfs

# chown -R username:username /media/sshfs

One system caveat for RHEL/CentOS was that the correct executable bit wasn't set for the fusermount command that SSHFS calls when you mount a file system. This may vary depending on your OS, but if you receive fusermount errors when using SSHFS, you can check the file and change it accordingly.

# chmod +x /bin/fusermount

You should now be able to mount a remote file system that your user has SSH access for. Run the sshfs command with any options you want. As usual, man sshfs will list any and all options sshfs has.

# sshfs remote_host:/opt /media/sshfs

# mount

sshfs#remote:/opt on /media/sshfs type fuse (rw,nosuid,nodev,max_read=65536,user=username)

As with any file system, you can mount whatever mount point you choose. In the example above, I mounted /opt on the remote side to /media/sshfs. If you wanted to mount the entire root mount point, substitute remote_host:/opt with remote_host:/.

Once the remote filesystem is mounted, you can use any local tools to work with and manipulate files and directories on the remote side. This makes it extremely easy to use commands like cp, vi, ls, rm, mkdir, and any other tools and scripts residing locally.

Disk Use Reporting

You might notice a bit of strange behavior that is actually quite normal when working with remotely mounted paths. Certain tools like df and du (used for disk reporting) won't report correct values or even any values at all. This is perfectly normal, so don't be alarmed. You have to remember that SSHFS is working across SSH and SFTP and therefore doesn't have the ability to report usage statistics to the user.

Security and Performance

One of the coolest things I find with an SSHFS-mounted file system is the fact that only the user who has the mount point mounted can access the volume. For instance, remotely mount a mount point with your non-privileged user, and then try to access the mount point using root. You'll get a "permission denied" because root doesn't have an established SSH connection through SSHFS.

The downside to SSHFS is a tradeoff. You'll trade speed and performance for ease of installation and lack of configuration. FUSE makes it extremely easy to use, but since all communications and file transfers are going across SSH, the information is encrypted on the local side and then decrypted on the remote side using CPU cycles. Depending on the host resources and connection speeds, SSHFS might not be well-suited for uses such as backups, which may or may not be an issue for you. SSHFS might not be the fastest protocol out there, but you can't deny the fact that SSHFS sure makes it easy and convenient to remotely mount a system you frequently need file access to.

If you don't have SSH set up currently on the systems you want to access, there's plenty of information available on the Internet about Linux and SSH. If you're interested in setting up SSH with keys instead of password login, search for the term "ssh keys" and you'll come up with plenty of resources demonstrating configurations.