SSHFS: Super Easy File Access over SSH

Tools like scp, sftp and rsync allow us to copy
files easily and securely between these accounts. But, what if we don't want to copy the
files to our local system before using them? Normally, this would be
a good place for a traditional network filesystem, such as NFS, OpenAFS
or Samba. Unfortunately, setting up these network filesystems requires
administrator access on both systems.

Enter SSHFS and FUSE

Luckily, as long as you have SSH access, you can use SSHFS to mount and use
remote directory trees as if they were local. SSHFS requires no special
software on the remote side, just a modern SSH server with support for
the SFTP extension. All modern Linux distributions support this
extension,
which was added to OpenSSH in version 2.3.0, released in November 2000.

SSHFS is built upon the FUSE user-space filesystem framework project. FUSE
allows user-space software, SSH in this case, to present a virtual
filesystem interface to the user. This is similar to how the /proc
and /sys filesystems present kernel internals in the form of files in a
directory tree. SSHFS connects to the remote system and does all the
necessary operations to provide the look and feel of a regular filesystem
interface for remote files.

Installing SSHFS and FUSE

I am using Fedora Core 4 on the workstation where I will be mounting the
remote directories. The remote system is also Fedora Core 4, but any *NIX
system running a modern SSH server with the SFTP extension will work. Your
Linux kernel also must have the user-space filesystems feature enabled,
either built-in or as a module.

All the software required for SSHFS is available as packages installable
with yum for Fedora Core 4. Simply run:

$ yum install fuse-sshfs

This installs SSHFS, FUSE and the fuse-lib dependencies
automatically. You also can build SSHFS from source, but more on that
later.

Before you can use SSHFS or any other FUSE-based filesystem as a nonroot
user, you must first add those users to the fuse group. In my case,
my user name is matt. This can be done from the command line as root
with the command:

$ usermod -a -G fuse matt

The fuse group lets you limit which users are allowed to use FUSE-based filesystems. This is important because FUSE installs setuid
programs, which always carry security implications. On a highly secured
system, access to such programs should be evaluated and controlled.

After installing and configuring the software, we are ready to give it a
whirl. To demonstrate the basic functionality, I will make a connection
to a remote system called my.randombox.com. The default operation for
SSHFS is to mount the remote user's home directory; this is the most common
use of SSHFS. Just like mounting any other filesystem, you need an empty
directory called a mountpoint under which the remote filesystem will be
mounted. I create a mountpoint named randombox_home, and then invoke
the sshfs command to mount the remote filesystem. Here is how it's done:

That's it. My home directory on my.randombox.com is now mounted under
the directory randombox_home on my local workstation. In the background,
FUSE, SSHFS and the remote SSH server is doing all the legwork to make my
remote home directory appear just like any other local filesystem. If you
want to mount a directory other than your home directory, simply put
it after the colon on the sshfs command line. You even can specify /
to mount an entire remote system. You will of course have access only to
the files and directories for which the remote user account has permission.
Everything else will get “Permission denied” messages. An example of
this is shown below:

SSH keys with empty passphrases are useless - in fact they are worse than useless, they are a liability. You might as well store your passwords to the remote system in plain text in a file called "README_all_passwords.txt"

This is great for users without root access on the storage server. But operations will be performed as the logged in user. I'm guessing that if you logged in as root, it might support automatically chown'ing.. but a) that requires trusted root login (which opens up security issues that even NFS doesn't) and b) uid mapping may become an issue like it is with any network storage.

Instead of having gnome mount the sshfs share upon startup one can use autofs instead. This is even easier. When ever I whish to acces a remote filesystem I just enter the the path /mnt/sshfs/foobar.com and then the autofs daemon mounts the remote filesystem for me.

I've written a small article on how to setup autofs and sshfs on my blog: http://www.tjansson.dk/?p=84 called "Autofs and sshfs - the perfect couple" if anybody is interested. :)

I don't know if anyone else had this problem, but to get it to work I had to do a chmod root:fuse on /dev/fuse.

Before I did that, logged in as tim(me) it gave me an denied error..had to use sudo and then it didn't work as only root was able to see the directory and use it properly. Kind of pointless if someone doesn't have sudo access!

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.