Security

Use the SSH Filesystem for secure network filesystem access

Network filesystem software can make your life easier. SSHFS provides an encrypted network filesystem so you can get convenience without sacrificing security.

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 insectmonger. On 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 umount command:

umount /home/alan/external

The [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.

The [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 -C option, 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.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

7 comments
Hillyman
Hillyman

Thank you for a wonderful post Chad. You covered a subject whose application I knew very little about and managed to turn it into a useful and powerful tool. Nice.

pgit
pgit

I use this a lot, one of the coolest things ever invented. Unlike samba, nfs and the others, there's very little overhead here and it really does consider the remote location to be part of the local file system. Only problem I ever had was it crashed a system while moving a huge data set, over 400GB. Not sure what the problem really was but I had to move it in smaller chunks to get it to work.

techrepublic@
techrepublic@

Both SMB or NFS are unsafe over the internet or on a intranet, if any system on it is compromised. The obvious solution is sshfs. Strong authentication and encryption. Also, the setup could not be easier. Just copy a user's public key to $HOME/.ssh/authorized_keys on the target system and voila. This fits well with my personal preference for a fine-grained access management where each system authenticates every user by itself. No central authentication for me thank you.

Neon Samurai
Neon Samurai

We actually looked for a win32 sshfs at work to provide a few specific machines with encrypted access to our data server. We ended up going with Truecrypt blob files hosted on samba shares since the only sshfs implementation for windows we could find was stuck at "good enough to work for the developer" status. I'd have loved to just grab an ssh share directly rather than add security on to CIFS. At home, it's very handy to pop open my PDA or any other naturally ssh enabled device as a directory tree. Rsync over ssh covers most sync needs but from time to time a mounted file system is the better way.

Neon Samurai
Neon Samurai

handy little command that will copy the user's public key to the target system for you.

Neon Samurai
Neon Samurai

All my systems where authenticating by cert within the same hour that I found that handy command. Previous to realizing that the command was right there, I'd only read the more complex methods including a crazy scp | cat >> file type of thing.

Editor's Picks