This is awesome.
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
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:
- Set up certificate authentication for your local root to the remote account on the remote machine, by use of
sudo ssh-keygenlocally, and the (remote account’s)
- Test the certificate authentication by verifying that the following command does not prompt for your remote password:
sudo ssh remoteuser@remotehost uptime
- 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/pathindicates a remote path.)
- Add the following line to your
/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.
- Copy the following into a new file
# # 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
remoteuseron the host
The second will be at
/mnt/ssh/remote2, and map to the directory
/remote/pathon the host
remotehost2, with the permissions of the user
characters to escape
: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
- Restart autofs to reload the configuration files:
sudo /etc/init.d/autofs restart
- Test it out! As root or the user indicated by
You should be greeted by the contents of the remote file system. Congratulations!
- 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).