This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!


Secure remote file management with sshfs

By Nathan Willis on November 21, 2005 (8:00:00 AM)

Share    Print    Comments   

It's a dangerous Internet out there, kids. If you are going to work on remotely connected machines, do it safely. Simple file transfers and interactive sessions have scp and ssh respectively; in fact there is hardly a commercial Web hosting provider left that doesn't support them. For more complicated scenarios we have VPN tools. But what if you need to work with files on a remote server, but find scp tedious in repetition and FreeS/WAN too cumbersome? You might find just what you're looking for in sshfs -- a tool for mounting a remote filesystem transparently and securely as if it were just another directory on your local machine.

sshfs is primarily the work of Miklos Szeredi, a Linux hacker from Budapest who is better-known as the creator of FUSE, the Filesystem in USErspace framework that makes sshfs possible. Szeredi was already working on FUSE when he discovered Florin Malita's similar project named LUFS and its SSHFS filesystem.

Szeredi liked the idea of an SSH-protected filesystem enough that he wrote a LUFS wrapper to allow him to use Malita's SSHFS in FUSE. Unhappy with the performance and lack of multi-threading, though, he eventually decided to implement his own sshfs native to FUSE.

The FUSE library and kernel module -- which joined the official Linux kernel in 2.6.14 -- enable non-root users and unprivileged programs to create and mount filesystems entirely in user space. This has led to a flurry of FUSE-based projects, providing filesystem interfaces to everything from USB-attached digital cameras to remote Gmail accounts.


But sshfs is one of the more straightforward FUSE filesystems, and thus a good place to begin for those new to FUSE. To get started, make sure that you have FUSE installed and working on your local machine. If your distribution is up-to-date, a binary package may be available to you already.

If not, you can download the source code for libfuse and the kernel module from the project's SourceForge page. Once it's installed, no further configuration is required, but you must issue a modprobe fuse command to make sure that the FUSE kernel module is loaded. You may also want to add yourself to the fuse group so you can work with FUSE without having to be root.

Next, download the sshfs source. Extract it and run ./configure and make && make install. sshfs utilizes OpenSSH's sftp package, so make sure that you have it installed on your local machine too.

You can connect to any other machine reachable via ssh; no special setup is required on the remote host. sshfs supports both SSH1 and SSH2 protocols, defaulting (as do most other tools) to SSH2. If you haven't used ssh before, you will need to generate a key pair and perform some basic ssh configuration. See the tutorials at for more help.


The general form for mounting an sshfs filesystem is sshfs username@remote_hostname:directory local_mount_point -- where username is the username of your account on the remote host. If it is the same as your local username, you may safely omit it and the @ sign.

If you do not specify a directory on the remote host, the user account's home directory is assumed -- but you must not omit the trailing colon in this case (e.g., sshfs ~/webstuff).

Once the remote directory is mounted, it behaves like any other local filesystem, visible to all scripts and applications, but over an end-to-end encrypted channel. You can browse and drag-and-drop files with Nautilus or Konqueror, edit files as if they were local, even work with a CVS repository.

When you are done working, the command fusermount -u local_mount_point unmounts the filesystem and tears down the connection.

If you intend to make regular use of an sshfs filesystem, you can add it to /etc/fstab and have it mounted automatically. Before doing this, however, make sure that the FUSE kernel module is loaded at startup time by adding it to /etc/modules.


Read and write performance is fast with sshfs. To get a feel for the system, I connected to an off-site backup server over my cable modem and tried to work my usual routine to compare real-world performance. I found no discernible time difference between commands acting on the remote system and local files. By contrast, NFS mounts frequently incur a noticeable lag, and WebDAV is slower than molasses.

Of course, two of the advantages to WebDAV are the collaborative editing of documents and revision tracking, which sshfs is not designed for. On the other hand, sshfs is far superior to scp because the entire command-line toolset operates on it.

For moving files from one machine to another, scp does a fine job -- but when it comes to searching, batch operations, cron jobs, or editing in place, sshfs wins hands down. As Szeredi told me, the convenience of filename auto-completion alone makes the whole system worthwhile.

sshfs reached version 1.0 last January. The current 1.3 release is essentially feature-complete, though Szeredi says there is still some work to be done. Certain command-line tools (such as df) do not work properly due to shortcomings in the OpenSSH implementation of sftp. To work around these holes, sshfs has to estimate disk usage and free space, which could complicate its usage for some tasks.

But even when it is completed, Szeredi points out that sshfs will not replace high-end systems like NFS or VPNs. It is intended only to provide fast, convenient access to remote directories, and do so securely, and with no configuration required on the remote host.

Share    Print    Comments   


on Secure remote file management with sshfs

Note: Comments are owned by the poster. We are not responsible for their content.


Posted by: Akhmad Fathonih on November 22, 2005 07:56 AM
Do you know that in KDE you can use konqueror to access your remote file via ssh. In KDE there's a protocol called fish will actually makes the remote file available like a local file.

Jut as simpel as: fish://



Posted by: on November 22, 2005 10:19 AM
I guess the difference between sshfs and KDE or GNOME's interface are:

sshfs: an admin can setup system-wide mount points of remote file systems for all users to utilize.

KDE/GNOME: user will be able to mount using their own desktop.

So, they got different purposes.



Posted by: Nathan Willis on November 22, 2005 10:50 AM
I should point out that there's a much longer discussion of this topic in the story page itself. Both the Konqueror issue and the mounting/unmounting dilemma (ie, you don't technically mount the remote directory under Konqueror's ssh connection method) are addressed. So be sure and check it out if you want more detail.



"fish://myhost.mydomain.myorg" (with Konqueror)

Posted by: Anonymous Coward on November 22, 2005 01:42 AM
Oh, boy.

This looks like a hell of a complication for end users to set up!

Try this instead: in Konqueror, type

--> "fish://host.domainname.toplevel"

into the address field (or "fish://ip_address"), and be surprised by the login prompt.

It works for 99% of all boxen where you already have an ssh commandline account.

It is KDE's implementation of a secure remote file management, via ssh, scp and sftp (which in the background drive the fish:// protocol).

Use "menu --> Window --> Split View Left/Right" to get two window panes. Move one of the two panes to point to your $HOME on your local machine (or to another fish://-ed account on another machine). Now transfer files easily by draggin'n'droppin' between the pains. Preview those weird "dsc0012345.jpg" files from your digicam by just hovering the mouse over them, and much more.

While FUSE is great for many-many-many use cases, it certainly isn't required for secure remote file management if you are a KDE user!


Re:"fish://myhost.mydomain.myorg" (with Konqueror)

Posted by: Anonymous Coward on November 22, 2005 09:51 PM
I had wanted to use GNOME's built-in support for mounting remote SSH directories as well until I realized that the rest of the system (command line and non-GNOME apps -- Azureus) don't recognize the mount.

I'd imagine that KDE suffers from a similar problem (command line and non-KDE apps -- Azureus) won't recognize the mount.

It really limits the usefulnes of those features for my usage pattern.


Re:"fish://myhost.mydomain.myorg" (with Konqueror)

Posted by: Anonymous Coward on November 28, 2005 06:25 PM
it does, but there were plans for supporting kde fish://, media:// and others through fuse so that they are available for all applications.

of course, that isn't extremly useful for ssh as there is sshfs, but for some 'protocols' that are not feasible to have their own fuse module this might be handy.


Re:"fish://myhost.mydomain.myorg" (with Konqueror)

Posted by: Anonymous Coward on June 20, 2006 12:55 AM
SSHFS works ok for a desktop in a stable LAN environment but isn't really a solution for laptops that may or may not be connected. Attempting to auto-mount resources that don't exist is an annoyance. For this reason, I stick with the Gnome built-in SSH mounts. They don't attempt to connect or authenticate until you actually use one so they don't produce a bunch of errors if you are offline.


Re:"fish://myhost.mydomain.myorg" (with Konqueror)

Posted by: Administrator on November 22, 2005 03:56 AM
Yeah, when I used KDE I absolutely loved it's network transparency. (I switched cause all the programs I used were GTK, it seemed prudent. Go figure.)

Gnome seems to sorta have network transparency
but it doesn't seem to work right, though I'm using Fedora Core 4 which is more than a tad beta. (It's supposed to be, I know.)

I rather wish Gnome and Windows had the same kind of network transparency abilities, because that's one feature about KDE that really kicks ass.


Re:"fish://myhost.mydomain.myorg" (with Konqueror)

Posted by: Nathan Willis on November 22, 2005 04:26 AM
For the record, GNOME's file manager Nautilus also handles SSH out of the box. You just type the URL ssh://user@hostname.tld etc in the address field. So you don't have to be a KDE user, either. I'm not sure about XFCE or other DEs.

What makes sshfs good is that it works without having to go through the GUI file manager; therefore it works for all command line tools, scripts, etc.

Also, I don't agree that the sshfs instructions in the article are more of a "complication" than any other method. A lot of the "complication" of using sshfs is really SSH complexity -- which users will need to do in order to access SSH shares via KDE or GNOME GUI clients as well. For a side-by-side comparison, you'd need to add that setup to the Konqueror instructions as well.

I also took some space to describe how to install FUSE, because users need to know how to do that until all distros ship with FUSE configured by default; for comparison's sake you'd have to add in instructions for installing Konqueror, or alternatively compare methods on a system with FUSE built-in.

And last but not least, part of the instructions relate to having sshfs mount remote SSH shares on startup, something not addressed in these Konqueror instructions. I don't even know if you can mount remote volumes on startup using Konqueror or Nautilus, but something tells me you can't, as they're interactive GUI apps.

Don't misunderstand me; I'm not knocking Konqueror. It's just that sshfs is extremely easy to set up, very difficult to mess up, and the parent post was really comparing apples and oranges.




Posted by: Anonymous Coward on November 22, 2005 07:54 AM
I like <a href="" title="">shfs</a> which does from what I can see the exact same thing but using the standard mount sytax (mount -t shfs [[user@]server:]/directory mountpoint). It also has a userspace tool shfsmount that you can use when not root mounting something not specially set up in fstab to be user-mountable.


Re:"fish://myhost.mydomain.myorg" (with Konqueror)

Posted by: Anonymous Coward on November 22, 2005 08:20 AM
In a GUI file manager, there's no concept of "mounting" - you just enter the URI and it works. Of course, sshfs is still better because it integrates natively with everything.


Re:"fish://myhost.mydomain.myorg" (with Konqueror)

Posted by: Administrator on November 22, 2005 09:17 AM
Well that's true, but it's still using KDE's network transparancy system and is limited to KDE software.

A lot of major software programs aren't KDE based.


Re:"fish://myhost.mydomain.myorg" (with Konqueror)

Posted by: Nathan Willis on November 22, 2005 10:46 AM
Well, yeah, clearly that's outside the normal usage of the GUI file manager; on the other hand I never use KDE so for all I know there is a "disk mounting" wizard/druid/clerk/shaman or whatever designed to give a colorful, translucent interface to fstab. Who knows.

Of course, I also meant to suggest sarcastically that interactive GUI apps never do anything that useful in the long term. Perhaps that got lost in the shuffle. To make up for it, I've gone back and added extra sarcasm to the above paragraph; taking subtle potshots at GUI apps in general. Hopefully posterity will judge the entire exchange as funny, if not helpful.

Wait a minute; I'm spending too much time replying to this post. You agreed with me about sshfs, after all. That's weird.... I should go find somebody who didn't. Ciao.




Posted by: Anonymous Coward on November 22, 2005 02:18 PM
Cool, but isnt there any tool where you can locally mount an remote FTP?



Posted by: Anonymous Coward on November 23, 2005 02:55 AM
Sure, it's called lufs, which replaced ftpfs.

<a href="" title=""></a>


Re:"fish://myhost.mydomain.myorg" (with Konqueror)

Posted by: Anonymous Coward on November 22, 2005 10:11 PM
...and is limited to KDE software.

You'd be mistaken on that point. Any application you wish, even a windows binary running under wine, can be called to interact with a remote file using KDE's fish://.

<nobr> <wbr></nobr>...Rob


it's more than open-edit-save-close

Posted by: Administrator on November 22, 2005 05:47 AM
Filesystem drivers, on any level, need to support a full range of file operations: open-close, read-write, seek-tell-stat, (maybe) mmap. Further, these operations should all work on the same inode (device:inumber).

NFS does all this. So does Samba.

fish:// in KDE and ssh:// in Nautilus do not. They simply transfer the file to a local mount point for the application, then transfer it back on program exit. This is all fine and good if you stick to the framework's file operations, but they fall apart when the framework is not available. Worse, even if you save often, if the desktop environment crashes due to a bug or power failure, all your work will be lost when the modified local copy fails to go back to the original location.



Posted by: Administrator on November 22, 2005 12:14 AM
I've been looking for something exactly like this.

I have a server at home running Apache and SQL and to access it's data from my office, I've always had to use FTP.

This would make things a lot easier and a lot more secure, as I could have a filesystem commonly accessable from my workstation at home AND at the office, completely file system transparent!



sshfs v. nfs

Posted by: Anonymous [ip:] on August 23, 2007 04:20 PM
Can anyone out there help me understand what NFS does that is so much better than SSHFS? After selling me on SSHFS, the article ends with: "...Szeredi points out that sshfs will not replace high-end systems like NFS...". In my production environment, I have 2 servers with mount points to a directory on a 3rd server. I initially set the mount up using sshfs, but after reading this, switched to nfs... I found sshfs to be much much faster... so can someone elaborate on why sshfs is not intended to replace nfs?
Thanks in advance!!


Re: sshfs v. nfs

Posted by: Anonymous [ip:] on January 07, 2008 06:06 PM

with all ssh based setups, everything will be done `as the logged in user' on the remote side. That works fine as long as you're alone (or maybe a small group). But as soon as you need some permission setup, you will need a remote filesystem which supports that. There NFS or friends come in;-)


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya