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 email@example.com: randombox_home firstname.lastname@example.org'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 email@example.com:/ randombox_slash firstname.lastname@example.org'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 $
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide