sshfs: Easy (and secure) access to a remote file system

April 22nd, 2007 edited by Tincho

Entry submitted by Diego Essaya. DPOTD needs your help, please contribute !

I’m sure you are already familiar with the ssh command. (If that’s not the case, maybe this article is not for you). Most likely you have also discovered scp ages ago. But it is probable that you have never heard of sshfs before.

SSHFS is a file system client based on the SSH File Transfer Protocol. It allows to mount a remote file system in your box, and use it as if it was a local directory. Besides the fact that it is a secure protocol, the main advantage of SSHFS is that it is very easy to setup and use. It has only two easy to meet requisites:

  1. The local system needs to have the FUSE kernel module loaded.
  2. The remote machine needs to be running a SSH server that understands the SSHFS protocol.


First of all we must install the SSHFS package in the local system:

# apt-get install sshfs

The package is available in both Debian and Ubuntu repositories.

Next, let’s make sure that condition #1 is met. In the local system, type (as root):

# modprobe fuse

This will load the FUSE kernel module. Besides SSHFS, the FUSE module allows to do lots of other nifty tricks with file systems, such as the BitTorrent file system, the Bluetooth file system, the User-level versioning file system, the CryptoFS, the Compressed read-only file system and many others.

As for condition #2, chances are it is already met: the OpenSSH server is
already installed and running in most Debian and Ubuntu systems. If this is not your case, just run the following command on the remote system:

# apt-get install ssh


Luckily, SSHFS is very simple to use. The following command:

$ sshfs user@host: mountpoint

will mount the home directory of the user@host account into the local directory named mountpoint. That’s as easy as it gets. (Of course, the mountpoint directory must already exist and have the appropriate permissions).

If you want to mount a directory other than the home directory, you can specify it after the colon. Actually, a generic sshfs command looks like this:

$ sshfs [user@]host:[dir] mountpoint [options]


The classic alternatives to access remote file systems are NFS and SMBFS. The main advantages of SSHFS are:

  • Easy to setup and run
  • Secure link

If you are sharing files between Windows machines, perhaps SMBFS is the best option. If you are not concerned about security and you need a faster alternative to SSHFS, go for NFS.


Posted in Debian, Ubuntu |

15 Responses

  1. Baruch Says:

    ssh is a transitional package, the real package is openssh-server.

  2. Frank Says:

    Hmm, this really is easy. But I have two additions. First, I found that the /usr/bin/fusermount command had permissions of 4750 and was owned by root:fuse, so I had to add my regular user ID to the “fuse” group via “usermod -G fuse -a frank” (leave out the quotes, of course, and put your username in there instead of mine). And because I didn’t want to log out and back in, I executed “newgrp fuse” so that I could test it. (Once I got it working, I exited out of the “newgrp” command and back to my login shell.)

    Second, the /dev/fuse device had permissions of 660 and was owned by root:root. I don’t know what the problem is here, since the “fusermount” command has root authority and should be able to access the device, but changing the group to “fuse” worked, so perhaps “fusermount” relinquishes root authority before accessing the device? If so, that’s probably a bug. I changed the group ownership to “fuse” and it worked fine.

    Last, I didn’t see any options on “sshfs” to break the connection when I was done, but “fusermount” has a “-u” option. So when I was ready to terminate the connection, I executed “fusermount -u” and the mountpoint name and the connection was broken cleanly.

    Very cool article — thanks for the write-up!

  3. Kamaraju Kusumanchi Says:

    The author missed one important advantage of sshfs as opposed to NFS, Samba.

    sshfs runs entirely in user space. A user using sshfs does not need to deal with the root account of the remote machine. In the case of NFS, Samba etc., the admin of the remote machine has to grant access to those who will be using the services. Not all the time the administrator of the remote machine will be willing to grant access for NFS etc.,

  4. thomas Says:

    It was not mentioned how to unmount, which is useful to know. :)

    fusermount -u mountpoint

  5. erik Says:

    Kamaraju has got a good point there. Sshfs is very handy because of that - a bit like what cifs is like in Windows world.

    Btw, the insecurity of “smbfs” is only the problem of the open source implementations that have to resort to legacy authentication modes and such.

  6. erkurita Says:

    You can also use sftp (secure ftp) if you want to access another computer in order to retrieve from or put in files in it.

    sftp does not require you to have an FTP server up or use port 21. sftp will use the same port option as ssh to connect to the said computer, using the sshd service. It also uses the standard ftp commands to work with it.

  7. Thinker Says:

    sshfs can be used in combination with afuse, too. This is great, it allows me to simply copy files to my webserver.

  8. fish:// protocol Says:

    In KDE you can already access remote machines via SSH transparently. Simply open “fish://username@host/path/to/whereever/”. The disadvantage is this only works in certain KDE programs like Konqueror. It doesn’t appear to work, say, in K3B. I might try this, since this obviously would work in *any* program.

  9. Mike O'Donnell Says:

    I had the same experience as Frank in comment #2, with permissions on fusermount and /dev/fuse. I have a vague memory that I may have disabled suid root for security reasons, so perhaps the suid setting for fusermount is ineffective. I believe (I am not a security expert myself) that suid root is disparaged by many.

    I hope that someone more knowledgable will comment on the permissions issues, particularly if there is a danger in changing the group ownerships of fusermount and /dev/fuse.

  10. Wolf Giesen Says:

    You should mention that mounting via fstab also works; you have to use a syntax like

    sshfs#user@host:/dir/ect/ory …

  11. jared Says:

    how does one set up an automount of this?

    so that it will mount when you boot up the machine?

  12. Diego Essaya Says:

    Thanks for all the comments!

    Regarding the permissions, I forgot to mention that the user must be in the ‘fuse’ group. If I recall correctly, no further setup should be needed. YMMV.

    When I said ‘easy to use’ I was implying that it runs entirely in userspace. Maybe I should have been more explicit :) Thanks for the remark.

    Another thing I forgot to include in the article :P. Look for previous comments. You can set it up via fstab like Wolf suggested, or use afuse like Thinker commented (didn’t know that).

  13. jared Says:

    @diego, tried the fstab a few months ago - problem was that when I boot up, if I was no longer at the office where the mounts were, the computer would fail to start up due to the ‘false’ fstab listings.

  14. Linulin Says:

    Talking about FISH front-ends don’t forget embedded FISH support in Midnight Commander (mc). Just use “cd /#sh:[user@]machine[:options]/[remote-dir]” inside mc to open remote side in one of the panels. Or hit F9, Left, Shell Link, F1 for more information.

  15. randomwalker Says:

    This is cool stuff. Makes things a lot easier for me.

    However, I have to ask, doesn’t it duplicate the work that gnome-vfs already does?