SSHFS: Super Easy File Access over SSH

Who needs NFS or Samba when you can mount filesystems with SSHFS?

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 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:

$ cd $HOME
$ mkdir randombox_home
$ sshfs  randombox_home's password: ************
$ ls -l randombox_home/
-rw-r-----  1 matt users     7286 Feb 11 08:59 sshfs.article.main.txt
drwx------  1 matt users     2048 Mar 21  2001 projects
drwx------  1 matt users     2048 Dec  1  2000 Mail
drwxr-xr-x  1 matt users     4096 Jun  8  2002 public_html
$ cp ~/my_web_site/index.html randombox_home/public_html/

That's it. My home directory on 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:

$ cd $HOME
$ mkdir randombox_slash
$ sshfs  randombox_slash's password:
$ ls -l randombox_slash/
total 0
drwxr-xr-x  1 root root   4096 Nov 15 10:51 bin
drwxr-xr-x  1 root root   1024 Nov 16 07:11 boot
drwxr-xr-x  1 root root 118784 Jan 26 08:35 dev
drwxr-xr-x  1 root root   4096 Feb 17 10:37 etc
drwxr-xr-x  1 root root   4096 Nov 29 09:30 home
drwxr-xr-x  1 root root   4096 Jan 24  2003 initrd
drwxr-xr-x  1 root root   4096 Nov 15 10:53 lib
drwx------  1 root root  16384 Nov 11 10:21 lost+found
drwxr-xr-x  1 root root   4096 Nov 11 10:38 mnt
drwxr-xr-x  1 root root   4096 Jan 24  2003 opt
dr-xr-xr-x  1 root root      0 Jan 26 08:11 proc
drwx------  1 root root   4096 Mar  3 09:34 root
drwxr-xr-x  1 root root   8192 Nov 15 13:50 sbin
drwxrwxrwt  1 root root   4096 Mar  5 18:41 tmp
drwxr-xr-x  1 root root   4096 Nov 11 10:55 usr
drwxr-xr-x  1 root root   4096 Jan 20 08:16 var
$ cat randombox_slash/etc/shadow
cat: randombox_slash/etc/shadow: Permission denied
$ ls -l randombox_slash/root/
ls: reading directory randombox_slash/root/: Permission denied
total 0
$ ls -l randombox_slash/home/matt/
-rw-r-----  1 matt users     7286 Feb 11 08:59 sshfs.article.main.txt
drwx------  1 matt users     2048 Mar 21  2001 projects
drwx------  1 matt users     2048 Dec  1  2000 Mail
drwxr-xr-x  1 matt users     4096 Jun  8  2002 public_html



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

SSHFS and Apache

Anonymous's picture

What about using sshfs to mount /var/www from a remote filesystem?

I keep getting a very generic 'Permission Denied' error when trying to chown /var/www (even as root) and under Apache I receive a 403 Forbidden error - again, very generic.


Anonymous's picture

This is not secure!!!!

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"

mount fatfs using fusermount command

Anonymous's picture

dear all,
how can i mount a fat fs using fusermount.. which uses a fusefat ....
thanks in advance,

one caveat

Anonymous's picture

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.

The only thing better is sshfs+autofs

Thomas Jansson's picture

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/ 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: called "Autofs and sshfs - the perfect couple" if anybody is interested. :)

Password without security weakness

Super Mike's picture

Instead of an empty passphrase, is there an smbpasswd-like way where I can generate the user/pass combo in an encrypted file and use that?

Or, what if I edited the C code with a hard-coded user/pass combo and compiled with that?

Great Think

WarDragon's picture

Yes, unlike nfs, this is what we want, easy to use and secure. Great

Thank you!

Shannon Coen's picture

This was just the solution I was looking for!

Very curious about FUSE now (GmailFS? cool!).

Thanks again,
Shannon Coen

sshfs article

meltedmossy's picture

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!