SSHFS: Super Easy File Access over SSH
As you can see from the above examples, I needed to type my password to complete the SSH connection to the remote system. This can be eliminated by creating a trust relationship between the local and remote user accounts. This is not appropriate in all situations, because it essentially makes the accounts equivalent from a security perspective. Any malicious activity on one account can spread to other systems via the trust, so take caution and fully understand the implications of setting up trust relationships. To begin setting this up, you need to create an SSH key pair, which consists of public and private key files named id_rsa and id_rsa.pub, respectively.
The public key is copied to the remote system and placed in the $HOME/.ssh/authorized_keys file. Some systems may use the filename authorized_keys2 in addition to or instead of authorized_keys.
This allows any user in possession of the private key to authenticate without a password. We create the key pair using the command ssh-keygen. The files are placed in the proper locations automatically on the local system in the $HOME/.ssh directory. Because we already have my remote home directory mounted, appending the public key to the authorized_keys file is extra easy. Below are all the steps required (assuming you created the equivalent of the randombox_home directory and mounted it):
$ cd $HOME $ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/matt/.ssh/id_rsa): <ENTER> Enter passphrase (empty for no passphrase): <ENTER> Enter same passphrase again: <ENTER> Your identification has been saved in /home/matt/.ssh/id_rsa. Your public key has been saved in /home/matt/.ssh/id_rsa.pub. The key fingerprint is: fa:e7:7c:e1:cb:7b:66:8b:67:07:05:99:7f:05:b9:4a matt@myworkstation $ mkdir randombox_home/.ssh $ chmod 700 randombox_home/.ssh $ cat .ssh/id_rsa.pub >> randombox_home/.ssh/authorized_keys $ chmod 600 randombox_home/.ssh/authorized_keys
In the above example, we create the key pair with an empty passphrase, then append the public key to the authorized_keys file in the remote home directory and set the permissions. After this is done, I no longer need to type the password when connecting to the remote account. To test this, first we unmount the remote home directory with the following command:
$ fusermount -u randombox_home
To test the trust relationship, we can try to run the uptime command on the remote system:
$ ssh email@example.com uptime 12:20:40 up 38 days, 4:12, 0 users, load average: 0.11, 0.04, 0.01
Good, no password needed. The trust relationship is working properly. If you have trouble getting this trust relationship to work, check the permissions on the files in .ssh on both systems. Many times lax permissions prevent SSH from using key files. Also, take a look at the syslog log files. OpenSSH's sshd server logs messages into syslog, which often are helpful in diagnosing key file problems. You may have to increase the logging verbosity level in the sshd_config file, usually found in /etc/ssh/.
You also can debug the connection by running ssh in the above example with the -vvv option to turn up verbosity. Now, let's mount the remote directory again. This time it does not prompt for my password:
$ cd $HOME $ mkdir randombox_home $ sshfs firstname.lastname@example.org: randombox_home $ ls -l randombox_home/ -rw-r----- 1 matt users 7286 Feb 11 10:33 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
In the last example, we configured and automated non-interactive mounting of a remote directory. Because we're no longer being prompted for a password, we can integrate SSHFS mounting into scripts, or better yet the GNOME desktop. To configure GNOME to mount our remote home directory automatically, we configure the SSHFS mount command as a session startup program. This is done from inside the Sessions preferences dialog. Navigate to Desktop→Preferences→More Preferences→Sessions->Add, and fill in the dialog as shown in Figure 1.
Upon the next login, GNOME automatically mounts the remote directory for me, as you can see in Figure 2.
Note that GNOME does not reliably kill this command upon exiting the session. You can unmount the remote directory manually using the fusermount -u randombox_home command. Another option is to automate the unmount by modifying the $HOME/.Xclients-default file to run the fusermount command as follows:
#!/bin/bash # (c) 2001 Red Hat, Inc. WM="gnome-session" WMPATH="/usr/bin /usr/X11R6/bin /usr/local/bin" # Kludged to run fusermount upon gnome logout. 20060301-MEH for p in $WMPATH ; do [ -x $p/$WM ] && $p/$WM; fusermount -u randombox_home; exit 0 done exit 1
Be aware that the .Xclients-default file is rewritten every time you run the switchdesk utility. You have to modify this file every time you use use the switchdesk utility to change your default desktop windowing manager.
Finally, you can add the appropriate sshfs commands in the boot startup file that is appropriate for your distribution. This way, your system will mount all the SSHFS directories automatically each time you boot your desktop.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Readers' Choice Awards
- BASH script to log IPs on public web server
3 hours 4 min ago
6 hours 40 min ago
- Reply to comment | Linux Journal
7 hours 12 min ago
- All the articles you talked
9 hours 36 min ago
- All the articles you talked
9 hours 39 min ago
- All the articles you talked
9 hours 40 min ago
14 hours 5 min ago
- Keeping track of IP address
15 hours 56 min ago
- Roll your own dynamic dns
21 hours 9 min ago
- Please correct the URL for Salt Stack's web site
1 day 21 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?