sshfs: Easy (and secure) access to a remote file system
April 22nd, 2007 edited by TinchoEntry 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:
- The local system needs to have the FUSE kernel module loaded.
- The remote machine needs to be running a SSH server that understands the SSHFS protocol.
Preparation
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
Usage
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]
Alternatives
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.
Links:
- SSHFS Homepage: http://fuse.sourceforge.net/sshfs.html
- FUSE: http://fuse.sourceforge.net/
April 22nd, 2007 at 6:36 am
ssh is a transitional package, the real package is openssh-server.
April 22nd, 2007 at 6:38 am
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!
April 22nd, 2007 at 8:05 am
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.,
April 22nd, 2007 at 11:22 am
It was not mentioned how to unmount, which is useful to know. :)
fusermount -u mountpoint
April 22nd, 2007 at 11:24 am
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.
April 22nd, 2007 at 1:10 pm
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.
April 22nd, 2007 at 9:44 pm
sshfs can be used in combination with afuse, too. This is great, it allows me to simply copy files to my webserver.
April 23rd, 2007 at 1:44 am
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.
April 23rd, 2007 at 2:11 am
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.
April 23rd, 2007 at 10:41 am
You should mention that mounting via fstab also works; you have to use a syntax like
sshfs#user@host:/dir/ect/ory …
April 23rd, 2007 at 12:48 pm
how does one set up an automount of this?
so that it will mount when you boot up the machine?
April 23rd, 2007 at 1:34 pm
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.
@Kamaraju
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.
@jared
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).
April 23rd, 2007 at 1:47 pm
@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.
April 23rd, 2007 at 9:31 pm
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.
April 23rd, 2007 at 10:33 pm
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?