I worked on this for something like 2 hours this afternoon, and finally tracked down all the nuances to get it working. I’m really pleased with the results, and hope that they can be of some to use to you as well, because I could not find a decent tutorial on this subject despite extensive Googling.

The Problem: Connect to a remote filesystem over SSH

Odds are if you’ve stumbled on this tutorial, you already know the problem: You want to access a remote file system over SSH. You want to use FUSE SSHFS, and you don’t want to ever have to think about it, so you’re looking for Autofs integration. To keep this to the point, I’m going to skip over the installation of these packages and just explain the configuration, especially since installation is very distribution specific. I’ll simply say on my system (Ubuntu Feisty) it consisted of:

sudo apt-get install sshfs autofs

The Solution

Getting SSHFS to work with Autofs really isn’t hard, you just need the magic configuration. Here’s how I got things working for me:

1. Set up certificate authentication for your local root to the remote account on the remote machine, by use of sudo ssh-keygen locally, and the (remote account’s) ~/.ssh/authorized_keys file.
2. Test the certificate authentication by verifying that the following command does not prompt for your remote password:

   sudo ssh remoteuser@remotehost uptime

3. Test that sshfs can establish the requisite connection:

   sudo mkdir /mnt/sshfs_temp
   sudo sshfs remoteuser@remotehost: /mnt/sshfs_temp
   sudo fusermount -u /mnt/sshfs_temp
   sudo rmdir /mnt/sshfs_temp

   Note that the : is required after the host to specify the remote directory. (: alone means the remote user’s home. :/remote/path indicates a remote path.)

4. Add the following line to your /etc/auto.master file:

   /mnt/ssh /etc/auto.sshfs        uid=1000,gid=1000,--timeout=30,--ghost

   Where /mnt/ssh is the path you want all ssh automounts to appear in,
   1000 is the UID of the user you want the sshfs mount to belong to (i.e., be writable by),
   1000 is the GID of the user you want the sshfs mount to belong to, and
   30 is the timeout in seconds to keep the FUSE connection alive.

5. Copy the following into a new file /etc/auto.sshfs:

   #
   # This is an automounter map and it has the following format
   # key [ -mount-options-separated-by-comma ] location
   # Details may be found in the autofs(5) manpage
   remote1     -fstype=fuse,rw,nodev,nonempty,noatime,allow_other,max_read=65536 :sshfs\#remoteuser@remotehost1\:
   remote2  -fstype=fuse,rw,nodev,nonempty,noatime,allow_other,max_read=65536 :sshfs\#remoteuser2@remotehost2\:/remote/path
   

   This creates two sshfs mappings (obviously, adding or removing lines creates more or fewer mappings).
   The first will be at /mnt/ssh/remote1, and map to the home directory of remoteuser on the host remotehost1.
   The second will be at /mnt/ssh/remote2, and map to the directory /remote/path on the host remotehost2, with the permissions of the user remoteuser2.
   Note the \ characters to escape # and : These escape characters are what took me two hours to track down: FUSE requires a parameter of the form: sshfs#user@host:directory, but autofs treats everything following a # as a comment, and the : character has a special meaning. These characters must be escaped by a \

6. Restart autofs to reload the configuration files:

   sudo /etc/init.d/autofs restart

7. Test it out! As root or the user indicated by uid above, run:

   ls /mnt/ssh/remote1

   You should be greeted by the contents of the remote file system. Congratulations!

The Problems

• This exact setup only works for one user due to specifying a uid. This is fine for a home desktop system, but will likely need further work to allow multiple users access to the remote filesystem. Perhaps careful usage of gid could alleviate this problem, though logging into the remote machine as a specific user still represents a security risk.
• I have not examined the architecture enough since I am only seeking to enable my home desktop system, so I cannot vouch for the security of this setup whatsoever. For example, the use of the allow_other option for FUSE may have security consequences since the mountpoint is created as root (to my understanding, at least).