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.
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.
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:
$ cd $HOME $ mkdir randombox_home $ sshfs firstname.lastname@example.org: randombox_home email@example.com'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 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:
$ cd $HOME $ mkdir randombox_slash $ sshfs firstname.lastname@example.org:/ randombox_slash email@example.com'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 $
|Natalie Rusk's Scratch Coding Cards (No Starch Press)||Feb 17, 2017|
|Own Your DNS Data||Feb 16, 2017|
|IGEL Universal Desktop Converter||Feb 15, 2017|
|Simple Server Hardening||Feb 14, 2017|
|Server Technology's HDOT Alt-Phase Switched POPS PDU||Feb 13, 2017|
|Bash Shell Script: Building a Better March Madness Bracket||Feb 09, 2017|
- Own Your DNS Data
- Simple Server Hardening
- Understanding Firewalld in Multi-Zone Configurations
- Teradici's Cloud Access Platform: "Plug & Play" Cloud for the Enterprise
- From vs. to + for Microsoft and Linux
- IGEL Universal Desktop Converter
- Bash Shell Script: Building a Better March Madness Bracket
- The Weather Outside Is Frightful (Or Is It?)
- Linux Makes Wi-Fi Happen in New York City
- Returning Values from Bash Functions