SSH is a time-tested, powerful, and generally outstanding utility for connecting two systems in a secure and efficient manner. Enabling anything from simple command-line access to full X Window sessions, it would appear there is almost no limit to what SSH can do. Reading on will only affirm this assertion, as two open-source projects – OpenSSH & FUSE – combine to provide secure, efficient, and stable access to remote locations as though they were local filesystem objects.
Without going into too many details, in order to present a filesystem to the user and, in general, most applications, information about files (file names, sizes, permissions, and general metadata) along with the actual file data is needed. SSH itself is perfectly capable of handling both. In fact, sftp (secure ftp), which utilizes SSH, is quite possibly the third most popular general file transfer protocal after HTTP and FTP. As the requiste information necessary for proper filesystem access is readily available through SSH, all that is needed to enable secure, transparent filesystem access to remote locations is a way to tie these methods together with the kernel’s filesystem routines. This is where FUSE comes in to play.
Traditionally, in Linux, due to its monolithic design, filesystem functions have been a component of the kernel. FUSE flips this idea on its head. As it’s full name, Filesystem in Userspace, explicitly exclaims, FUSE places the filesystem routines within userspace as opposed to kernelspace. As a result, adding support for disparate filesystems is as simple as installing the routines for them. There is no need to recompile the kernel or anything of the sort. It is as simple an operation as loading up a user application such as Firefox. As a result, FUSE has been used for an unbelievably large number of filesystem implementations of almost every possible type.
Now that we understand the basic premise of FUSE, it shouldn’t be that great of a jump to understand how fuse-sshfs works. Take one part ssh, one part fuse, a dash of freedom, and voilà – we have a remote filesystem location mounted as a local resource. All filesystem operations and transfers are securely encrypted.
For an example of how flexible this is, I am currently listening to this file directly from the server’s filesystem via fuse-sshfs. Though I am physically streaming the file over the Internet, Audacious sees the file as a local resource. fuse-sshfs takes care of all filesystem resources. While there are obvious performance considerations with regards to bandwidth and latency, those would be present with any realtime solution providing a similar service. For simple operations such as fetching directory listings, opening individual files, and even copy files to-and-from the remote system, you will likely see performance within the acceptable range of a normal computing session.
“Enough, Basil! Tell me how to do it already!”
Alright, alright. Brace yourself for the most complicated part of this article.
First, if you don’t have the FUSE library installed, download and install it. It’s a simple
yum install fuse-sshfs
On systems with yum support (e.g., Fedora)
You can download the sources from the FUSE website and compile & install them with the following commands (download and extract the files first):
./configure
make
make install
Likewise, do the same for the fuse-sshfs package
./configure
make
make install
With FUSE and fuse-sshfs now installed, you mount the remote location with the following command:
sshfs hostname: mountpoint
So, for example, let’s say you want to mount the directory /home/my.remote.username located on the server www.example.com. Additionally, you’d like to mount it at the location ~/my.remote.username@example.com. The command would look akin to this (depending on how your system implements user home directories – my assumption is Fedora Core 6):
sshfs my.remote.username@example.com:/home/my.remote.username /home/my.local.username/my.username@example.com
Can it get anymore difficult? Yes, if you’re running SSH on a differnet port, just pass the port number as the parameter to the -p argument prior to the hostname portion:
sshfs -p 1234 my.remote.username@example.com:/home/my.remote.username /home/my.local.username/my.username@example.com
There is a host of other options that are available for configuration. A standard sshfs -h call will show you what’s available.
There is one caveat I discovered using fuse-sshfs, at least on Fedora Core 6 on my laptop and at work (laptop is 32bit, work is dual-core 64bit). The sshfs binaries are, by default, given execute permissions only to the owner and the group – neither of whom are you by default (owner is root, group is fuse). This can be resolved by adding yourself to the fuse group. Look up how to do that, because it may be different on your system. With Fedora Core 6, it’s a simple call to the Users and Groups applet under the “Administration” section of the “System” menu.
Another issue to keep in mind is that if you mount a subdirectory (as we have in the example0, then you cannot have access to any directories above (e.g., the home directory). You only have access to the directory which you’ve mount, and those below it. Additionally, I noticed strange behavior with symlinks – it appears they are not derefenced and then corrected for the local system, so they are likely not to work correctly.
Aside from those two major issues, fuse-sshfs has amazed from the moment I tried it out, and I am finding it more-and-more useful as I try it different contexts. If I discover anything else interesting, good or bad, I will either update this post or share it within a comment. I invite anyone else that tries it to do the same. If anyone has any questions or problems, feel free to post, and if I know the answer, I’ll try to offer a solution.