sshfs is a secure file system client that allows you to access and manipulate files on remote systems where that would normally be available via SFTP. sshfs is dependent upon FUSE or Filesystem in Userspace. FUSE is available for Linux, FreeBSD, NetBSD (as PUFFS), OpenSolaris, and Mac OS X (as MacFUSE). It was officially merged into the mainstream Linux kernel tree in kernel version 2.6.14. h1.

The Pieces of the Puzzle

You will need to install three applications / frameworks:

1. MacFuse
2. Macfusion
3. sshfs (to update the pre-installed version that comes with Macfusion)

Installing MacFuse

MacFuse is an OS X implementation of the Filesystem in Userspace (FUSE) framework. FUSE provides an API to write a virtual file system. Variations of the virtual file system include:

• PicasawebFS, for manipulation images in a Picasa account like they were stored on your local machine
• RSSFS, which allows you to mount an RSS feed as a filesystem and access each entry as an individual file
• SSHFS, or the Secure Shell Filesystem, which allows you to mount a remote computer directory through a secure shell (SSH) login.

Download and install MacFuse from Google Code: http://code.google.com/p/macfuse

At present the preference pane that MacFuse installs is 32-bit, so your System Preferences will restart in 32-bit mode when you select the MacFuse pane. The only option it exposes is a check for updates.

Installing Macfusion

Macfusion is an open source SSHFS mounting application for Mac OS X.

Download and install from: http://www.macfusionapp.org

Setting up an SSHFS file system

Once Macfusion is installed, start the application and click on the plus icon in the bottom left of the main window and choose SSHFS.

Set SSHFS mount parameters

Under the SSH tab:

• Host: The _hostname_ of the server that you SSH to.
• User name: Your SSH username.
• Password: Your SSH password. (At present I don’t know how to enable this via SSH Keys.)
• Path: This can be left blank.

Under the SSH Advanced tab:

• Port: The default SSH port is 22 unless the server uses a different one.
• Follow Symbolic Links: Leave this checked

Under the Macfusion tab:

• Mount Point and Volume Name: Can be left blank.
• Ignore Apple Double Files: You must uncheck this if you plan to open/edit/save files on the mounted volume. While allowing for remote editing of files is a powerful feature there is a downside. Mac OS X will place .DS_Store and ._* (Apple double) files on the server. OS X utilizes these hidden files for enhanced filesystem features and extended attributes in non-OS X filesystems. Since they start with a dot (.) these files should be invisible on the remote system. You may leave this option checked if you only plan to copy/move/delete files (it will also increase speed).
• Enable Negative VNode Cache: This is an optimization to increase speed and should generally be left checked, unless files can appear on the mounted volume from the server side of the connection. For example, if multiple users are using your mounted disk space leave this unchecked.

Mounting the Remote filesystem

You are now ready to mount the SSHFS on your desktop. Click on the mount button and if the SSH settings are correct you should have a green disk icon mounted on the desktop. (Note, you may need to visit the Finder preferences to make sure that you are allowing *Connected Servers* to be displayed.) You should now be able to access the remote files as if they were on an external disk attached to your system. You can copy, move, rename, and delete files. Remember, that in order to edit files you must uncheck the Ignore Apple Double Files option. This can only be done with the remote filesystem is unmounted.

sshnodelay.so Error

If the mount operation fails, click the gear icon in the Macfusion main window and select the Log option (or use Cmd-L with Macfusion as the active application). If you see the following error message:

dyld: could not load inserted library: /Applications/Macfusion.app/Contents/Plugins/sshfs.mfplugin/Contents/Resources/sshnodelay.so

Then you need to rename or remove that library. Navigate to the /Applications/Macfusion.app/Contents/Plugins/sshfs.mfplugin/Contents/Resources directory and rename (e.g., sshnodelay.orig) or remove the sshnodelay.so file.

Update SSHFS

Now that you have a working connection it is time to verify the version of sshfs included with Macfusion, and update it if necessary. Using the Terminal, navigate to:

$ cd /Applications/Macfusion/Contents/Plugins/sshfs.mfplugin/Contents/Resources

The copy of sshfs that Macfusion uses is located in this directory. Run the command:

 $ ./sshfs-static -V

to verify the installed version. As of this writing the current available version of sshfs was 2.2, if the displayed version is anything less than that, you will see a performance increase by updating.

Download SSHFS from: http://code.google.com/p/macfuse/wiki/MACFUSE_FS_SSHFS

For Mac OS X 10.6 you want to get the sshfs-static-leopard.gz file. Uncompress the gzip archive. Inside the resulting sshfs-binaries folder will be an application called sshfs-static-leopard. In Terminal rename the original sshfs-static application (assuming you are still in the /Applications/Macfusion/Contents/Plugins/sshfs.mfplugin/Contents/Resources directory):

$ mv sshfs-static sshfs-static-orig

And then copy the new version into place:

$ mv ~/Downloads/sshfs-binaries/sshfs-static-leopard sshfs-static

This should result in a significant performance increase.

Preventing .DS_Store files over Network Connections

You can prevent .DS_Store files from being created on the mounted filesystem by executing the following command in Terminal:

$ defaults write com.apple.desktopservices DSDontWriteNetworkStores true

This will affect interactions with SMB/CIFS, AFP, NFS, and WebDav servers. You will need to restart the computer or log out and back in to your user account for this change to take effect.

The files I deleted where the public and private key pair that uniquely identify my work desktop, and the list of public keys my work desktop has added to its authorized keys list. No real harm done except that now when I try to remotely login to that computer I have to enter the password. I decided to start over and document the process so I can perform it again in the future, if need be.

Step One

Generate a key pair on each machine you regularly use. In my case I have two work computers, a desktop called Palantir and a laptop called Orthanc, and two personal computers, both laptops, called Eeyore and Tigger. On Unix based systems run the ssh-keygen command to create a new public and private key pair. Like this:

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/mhn/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/mhn/.ssh/id_rsa.
Your public key has been saved in /Users/mhn/.ssh/id_rsa.pub.

The id_rsa file is my identification and private key. The id_rsa.pub file is my public key. In order to make copying the public key to other machines easier I made a copy of the id_rsa.pub file on each machine, using the machine’s name as a unique identifier.

$ cp id_rsa.pub machineName.pub

Step Two

Next I copied the public keys from each machine into a folder in my Dropbox:

$ cp .pub ~/Dropbox/public_keys/

Since I can access my Dropbox from all of my machines, and since the key files are named for the machine they represent, this is a elegant way to house them centrally. You could also use scp (secure copy) to accomplish the same thing:

$ scp machineName.pub you@othermahince.com:~/.ssh

Step Three

Once you have the key files on the remote machine or in  your Dropbox, ssh (secure shell) into that machine and change to the .ssh directory.

$ ssh you@remoteMachine.com
Password:
$ cd .ssh

Make sure the authorized_keys file exists in the .ssh directory using the touch command.

$ touch authorized_keys

Concatenate the public key from the other machine to the authorized_keys file,

$ cat machineName.pub >> authorized_keys

Repeat the concatenation for each machine you want access this computer from remotely.

Step Four

There is no step four. You’re done.

Step Five

I also used the named public key files to allow password-less access to my bitbucket account.

NB: These steps worked for me. You should probably read more about ssh keys, scp, and ssh before attempting to follow them. Especially if you’ve never done this before.

Currently I have a situation where I’d like to share my music to a computer that isn’t on the same subnet. It turns out this is possible, if a bit cumbersome. I’m basing my instructions below on the much more detailed instructions I found the SSH Tunnel MtdWiki.  

Make sure you can establish a secure shell (ssh) connection from the client (listening) computer and the server (playing) computer. Open Terminal and type

ssh userid@192.168.1.1

where userid is the user account you have on the computer you’ll be using as the server. And where 192.168.1.1 is the IP address that machine has.

If this works then you are ready for the next step. If it doesn’t work, you’ll need to visit the Sharing preference pane (for Mac OS X 10.4.x) and make sure that Remote Login is enabled. While you are there, make sure that iTunes Music Sharing is also enabled.

Step two is to create a secure shell tunnel between the listening computer and the playing computer. One of the more useful features of ssh tunnels is the ability to forward a port from one computer to another. Services that listen to or respond at specific ports can be forwarded through a ssh tunnel to remote machines. iTunes uses port 3689 for sharing music. We want to establish a tunnel between our two computers that ties port 3689 on the listening computer to port 3689 on the playing computer. Something like this:

ssh userid@192.168.1.1 -N -f -L 3689:192.168.1.1:3689

Here’s a breakdown of the command:

ssh userid@192.168.1.1 is the normal secure shell login command. The -N flag makes it a non-interactive session, and the -f flag causes the whole command to run in the background, both of which free up your command line for other activities. The -L flag establishes the port forwarding from port 3689 on the listening machine to the same port on the playing machine.

Next you will need to install a Network Beacon, which allows iTunes to see the DAAP port (3689). The one I used is freely available from Chaotic Software. Since iTunes is geared to only “see” shared music from the same subnet, you need something to act as a proxy for the remote server. In this case Network Beacon acts as that proxy, allowing the copy on the listening machine to see the music on the playing machine through the secure tunnel and port forward we created above.

Here’s an image of how to configure the beacon on the listening machine:

With the beacon enabled, and the tunnel established, start iTunes on your listening computer and wait a few moments while the shared library is populated under the “Shared” heading in the sidebar.

SCP

Secure copy, or scp, encrypts data being transfered so that man-in-the-middle attacks aren’t possible.  I’ll show you the original script, and then  my script which employs scp instead of ftp.  I’m also using a private-public key pair for authentication, so that there is no need for my host password to be either transmitted or stored in the script.

The Original Script

#!/bin/sh
#mark as executable
# get the uptime data
days=$(uptime | awk '{print $3}' | sed 's/,//g')
hours=$(uptime | awk '{print $5}' | sed 's/,//g')
label=$(uptime | awk '{print $4}')
 
if [ "$days" = 1 ]; then
  day_label='day'
else
  day_label='days'
fi
 
#format labels
if [ $hours = 1 ]; then
  hour_label='hour'
else
  hour_label='hours'
fi
 
#format output
if [ "$label" = 'mins,' ]; then
  echo 'My MacBook has been on for '$days minutes'' > uptime.txt
elif [[ "$label" = 'day,' || "$label" = 'days,' ]]; then
  echo 'My MacBook has been on for '$days $day_label, $hours $hour_label'' > uptime.txt
elif [ "$label" = '2' ]; then
  echo 'My MacBook has been on for '$days hours'' > uptime.txt
fi
 
#upload to the website
hostname="FTP address"
username="FTP username"
password="FTP password"
 
ftp -n $hostname <<EOF
 
quote USER $username
quote PASS $password
cd /path/to/wordpress/uploads
put uptime.txt
EOF
 
#move the uptime file back to its original place
mv uptime.txt /path/to/file
 
echo "task completed"

As you can see, in the “upload to the website” section of the script, the host user id and password are stored.  While this works, it is probably not the best approach.  By generating a ssh key pair, we can eliminate the need for the user id and password, and we can clean up the code using scp.

ssh-keygen

Run this command in Terminal:

ssh-keygen -t rsa

This program creates a pair of encryption keys, public and private, using the RSA encryption scheme. It will prompt you for a filename where it will save the private key. (The public key will be created with the same filename, but with an additional .pub extension.) By default, it will want to save the key as~/.ssh/id_rsa, which, being one of the default filenames for keys that scp (and ssh) recognizes, will be perfect for our purposes.  Hit return to enter a blank pass phrase, and then return again to confirm a blank pass phrase. (Using ssh-agent would allow using a pass phrase protected key, but that is beyond the scope of this posting.)

Next you want to log onto the remote machine, your web host, and create (if it doesn’t already exist) a .ssh directory.  Note the leading dot, which makes this directory hidden to the normal ls command.  To see if you already have one, type

ls -a

at the command prompt on your web host. 

Once you’ve created the .ssh directory you are ready to copy the public half of the key pair to your host.  The public key on your local machine will (by default) be called id_rsa.pub.  We are going to rename it as we copy it to the remote machine to authorized_keys2.  (If you already have an authorized_keys2 file on the remote machine, you will need to concatenate the new key to the exiting ones.)

We’ll use the scp command to copy, and rename, the public key:

scp id_rsa.pub yourid@remotehost.com:~/.ssh/authorized_keys2

You will have to provide the correct values for yourid and the remotehost.com name.  Since we haven’t yet copied the key to the remote machine you will be asked for your password.  In the future, however, having the keys setup will let this command, and others like it, run without requiring a password.

With our keys in place we can now modify the uptime script to use scp.  

The Modified Script

#!/bin/sh
# timeup.sh
 
# get the uptime data
days=$(uptime | awk '{print $3} ' | sed 's/,//g')
hours=$(uptime | awk '{print $5} ' | sed 's/,//g')
label=$(uptime | awk '{print $4} ')
 
if [ "$days" = 1 ] ; then
day_label='day'
else
day_label='days'
fi
 
# format labels
if [ $hours = 1 ] ; then
hour_label='hour'
else
hour_label='hours'
fi
 
# format output
if [ "$label" = 'mins,' ] ; then
echo 'My Powerbook has been on for '$days minutes'' > uptime.text
elif [[ "$label" = 'day,' || "$label" = 'days,' ]] ; then
echo 'My Powerbook has been on for '$days $day_label, $hours $hour_label'' > uptime.text
elif [ "$label" = '2' ] ; then
echo 'My Powerbook has been on for '$days hours'' >> uptime.text
fi
 
# upload to web host
# relies upon ssh-key for authentication
scp uptime.text id@remotehost:/path/to/wordpress/uploads/uptime.textontent/uploads/uptime.text
 
echo "task completed"

Now you can follow the rest of the steps at the Automatically update your computer’s uptime on your website article, and know that your information is being copied without exposing your id, password, or the file contents thanks to scp and ssh-keygen.