A number of different ways of accessing files on remote filesystems exist. Some general categories of access methods are more useful than others under specific circumstances. One such category falls under the heading of “network filesystem”. Network filesystem software provides a way to treat a filesystem on a remote computer as though it was part of the local filesystem, though how seamless an illusion it provides depends on a lot. It depends on the operating systems involved, the filesystem browsing interface, access times affected by network bandwidth and latency, and other factors.
One of the best-known examples of network filesystem software is Microsoft’s CIFS, which allows for the MS Windows “mapped network drive” and network “browsing” with Windows Explorer. Another is NFS — originally developed by Sun — which has been available for descendants, relatives, and imitators of the original AT&T UNIX for fifteen years. These two examples make up the majority of network filesystem deployments in the world, though dozens of other examples exist.
Encrypted network filesystems can provide secure remote filesystem access even across unsecured networks. On secured networks, it is still a good idea to use encryption when transfering data across the network, for the sake of layered security. On systems that have OpenSSH installed, such as almost every open source Unix-like OS installation in the world, SSHFS — the SSH Filesystem — can prove the perfect option for easy and secure network filesystem access to data stored on a remote computer.
Based on SSH as it is, to install and use SSHFS on the client computer, you will need to have OpenSSH installed. Pretty much every major Linux distribution and BSD Unix operating system comes with OpenSSH installed by default, so it is unlikely you will need to install it separately. In addition, the server — the computer whose filesystem you want to be able to access from the local client system — needs to have the OpenSSH server process running.
The SSH Filesystem also depends on FUSE, the “Filesystem in Userspace”. FUSE provides an API on Unix-like systems for developing high-level filesystems that can be managed securely without necessarily requiring root access. Luckily, the software management systems of the major open source Unix-like operating systems should handle dependencies automatically for you.
When using a source-based software management system, however, you may need to ensure that you have kernel headers installed with the OS wherever the build system expects them to be stored for FUSE to install properly. With FreeBSD’s Ports system, for instance, you can specify that all system headers should be installed during the operating system installation process.
Once you have ensured FUSE and SSHFS are installed on the system, mounting remote filesystems is an incredibly easy task. It is, in fact, the simplest combination of what one would expect from the
mount command (used to mount a local filesystem) and the
ssh command (used to open a shell on a remote computer).
In addition to being simple to use, SSHFS also allows for arbitrary subdirectory selection both when choosing what to mount and where to mount it. As long as you have SSH access to a given directory on the remote system, you can use SSHFS to mount it locally across a secure, encrypted network connection.
The syntax for mounting a remote filesystem locally using SSHFS, as shown in the SSHFS manpage, is:
sshfs [user@]host:[dir] mountpoint [options]
Let us examine a simple example.
Alan has a directory containing Ogg Vorbis music files on a FreeBSD server with the hostname
unruly, and wants to mount that directory for local access on his Debian laptop, named
unruly, the location of the music directory is
/usr/home/alan/vorbis. The filesystem location where he wants to mount it on his laptop is
/home/alan/external. The username on both machines is the same, “alan”. The command he might use is:
sshfs unruly:/usr/home/alan/vorbis /home/alan/external
Unmounting can be accomplished with a simple command as well. As specified in the manpage for SSHFS, Alan could unmount with:
fusermount -u mountpoint
Thus, he would type:
fusermount -u /home/alan/external
He could just as easily use the normal
[user@] part of the
sshfs command syntax example from the manpage is used to specify a user account on the remote machine, in cases where the remote filesystem you want to access is “owned” by an account with a different username than the username you use on the local machine where you want to mount it.
[options] part of the command syntax example is for any of the more than 50 options described in the SSHFS manpage — much more than can be explained in a single article. Among the most likely options you might need are:
sshfs -hThis provides simple syntax help if you need a quick refresher in the available options just before you type an SSHFS command.
sshfs [user@]host:[dir] mountpoint -p 2002This allows you to connect via a port other than the default SSH port 22, in case the SSH server you must contact to access the remote filesystem is configured to use a nonstandard port.
sshfs [user@]host:[dir] mountpoint -CWith the
-Coption, you can enable SSH compression. On low-bandwidth networks with high traffic demands, such as the Internet, this can speed up effective access times for remote filesystems mounted via SSHFS.