Secure remote file management with sshfs

It's a dangerous Internet out there, kids. If you are going to work on remotely connected machines, do it safely. Simple file transfers and interactive sessions have scp and ssh respectively; in fact there is hardly a commercial Web hosting provider left that doesn't support them. For more complicated scenarios we have VPN tools. But what if you need to work with files on a remote server, but find scp tedious in repetition and FreeS/WAN too cumbersome? You might find just what you're looking for in sshfs -- a tool for mounting a remote filesystem transparently and securely as if it were just another directory on your local machine.

sshfs is primarily the work of Miklos Szeredi, a Linux hacker from Budapest who is better-known as the creator of FUSE, the Filesystem in USErspace framework that makes sshfs possible. Szeredi was already working on FUSE when he discovered Florin Malita's similar project named LUFS and its SSHFS filesystem.

Szeredi liked the idea of an SSH-protected filesystem enough that he wrote a LUFS wrapper to allow him to use Malita's SSHFS in FUSE. Unhappy with the performance and lack of multi-threading, though, he eventually decided to implement his own sshfs native to FUSE.

The FUSE library and kernel module -- which joined the official Linux kernel in 2.6.14 -- enable non-root users and unprivileged programs to create and mount filesystems entirely in user space. This has led to a flurry of FUSE-based projects, providing filesystem interfaces to everything from USB-attached digital cameras to remote Gmail accounts.

Preparation

But sshfs is one of the more straightforward FUSE filesystems, and thus a good place to begin for those new to FUSE. To get started, make sure that you have FUSE installed and working on your local machine. If your distribution is up-to-date, a binary package may be available to you already.

If not, you can download the source code for libfuse and the kernel module from the project's SourceForge page. Once it's installed, no further configuration is required, but you must issue a modprobe fuse command to make sure that the FUSE kernel module is loaded. You may also want to add yourself to the fuse group so you can work with FUSE without having to be root.

Next, download the sshfs source. Extract it and run ./configure and make && make install. sshfs utilizes OpenSSH's sftp package, so make sure that you have it installed on your local machine too.

You can connect to any other machine reachable via ssh; no special setup is required on the remote host. sshfs supports both SSH1 and SSH2 protocols, defaulting (as do most other tools) to SSH2. If you haven't used ssh before, you will need to generate a key pair and perform some basic ssh configuration. See the tutorials at OpenSSH.com for more help.

Connection

The general form for mounting an sshfs filesystem is sshfs username@remote_hostname:directory local_mount_point -- where username is the username of your account on the remote host. If it is the same as your local username, you may safely omit it and the @ sign.

If you do not specify a directory on the remote host, the user account's home directory is assumed -- but you must not omit the trailing colon in this case (e.g., sshfs nate@www.nateshandmadedoilies.com: ~/webstuff).

Once the remote directory is mounted, it behaves like any other local filesystem, visible to all scripts and applications, but over an end-to-end encrypted channel. You can browse and drag-and-drop files with Nautilus or Konqueror, edit files as if they were local, even work with a CVS repository.

When you are done working, the command fusermount -u local_mount_point unmounts the filesystem and tears down the connection.

If you intend to make regular use of an sshfs filesystem, you can add it to /etc/fstab and have it mounted automatically. Before doing this, however, make sure that the FUSE kernel module is loaded at startup time by adding it to /etc/modules.

Observation

Read and write performance is fast with sshfs. To get a feel for the system, I connected to an off-site backup server over my cable modem and tried to work my usual routine to compare real-world performance. I found no discernible time difference between commands acting on the remote system and local files. By contrast, NFS mounts frequently incur a noticeable lag, and WebDAV is slower than molasses.

Of course, two of the advantages to WebDAV are the collaborative editing of documents and revision tracking, which sshfs is not designed for. On the other hand, sshfs is far superior to scp because the entire command-line toolset operates on it.

For moving files from one machine to another, scp does a fine job -- but when it comes to searching, batch operations, cron jobs, or editing in place, sshfs wins hands down. As Szeredi told me, the convenience of filename auto-completion alone makes the whole system worthwhile.

sshfs reached version 1.0 last January. The current 1.3 release is essentially feature-complete, though Szeredi says there is still some work to be done. Certain command-line tools (such as df) do not work properly due to shortcomings in the OpenSSH implementation of sftp. To work around these holes, sshfs has to estimate disk usage and free space, which could complicate its usage for some tasks.

But even when it is completed, Szeredi points out that sshfs will not replace high-end systems like NFS or VPNs. It is intended only to provide fast, convenient access to remote directories, and do so securely, and with no configuration required on the remote host.