Autofs and sshfs – the perfect couple

What is sshfs and why is it so great?

sshfs is a file system in userspace (FUSE) and can be used to mount a remote ssh account locally in a folder. This is absolutely great – If I need to work on files from my server I can use the simple command:

tjansson@dirac:~$sshfs tjansson@bar.com: sshfs/

which mounts the remote file system on bar.com over a encrypted connection to the folder sshfs/ – none of the programs is aware the files are remote and working on a file in the folder sshfs/ is the same as for local files – at least if the connection is fast enough.

What is autofs and what why is this even better than plain sshfs?

The great thing thing about autofs is that the line above is no longer needed. The mounting of the remote file system is done in the moment I try to access the folder by the autofs daemon. sshfs and autofs together makes a encrypted remote file system available to the user and the system in a totally transparent way. Once the setup is complete the user will never need to know that the files are actually on a remote server.

Installation of FUSE
The installation is pretty straight forward. First the packages needs to be loaded.

root@bohr:~# aptitude install sshfs fuseutils autofs

Second the module needs to be loaded into the kernel:

root@bohr:~# modprobe fuse

and since this module should be loaded on every startup of the computer the line:

fuse

should be added to the file /etc/modules. The last part of setting up FUSE is to add the users which should be able to use FUSE to the FUSE usergroup.

root@bohr:~# usermod -a -G fuse tjansson

This will work when logged out and in again.

Configuring ssh and autofs
First I need to create a set of ssh-keys so I don’t have to write my password every time the connection is established.

root@bohr:~# ssh-keygen -t dsa

Next the public key needs to be transported to the remote server (bar.com) with the login “tjansson”.

root@bohr:~#ssh-copy-id -i .ssh/id_rsa.pub tjansson@bar.com

Now I need to create a folder where the remote folder should be mounted.

root@bohr:~# mkdir /mnt/sshfs

The next thing is to add a line to the file /etc/auto.master but before this is done. I need to know the userid, so I run:

tjansson@bohr:~$cat /etc/passwd | grep tjansson
tjansson:x:1000:1000:Thomas Jansson,,,:/home/tjansson:/bin/bash

So my userid is 1000. The file in /etc/auto.master now needs the line:

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

and finally we need to create the file /etc/auto.sshfs and add lines similar to this:

bar -fstype=fuse,rw,nodev,nonempty,noatime,allow_other,max_read=65536 :sshfs\#tjansson@bar.com\:

This will mount the remote system in the folder /mnt/sshfs/bar/ every time I access that folder. If I’m not using the folder for 30 seconds it will be unmounted. Absolutely amazing and very very useful.

Final words
If you have several servers you just need to add line for each in the file /etc/auto.sshfs. Finally it should also be stated that the are some security considerations to take into account. If this done on a laptop and the laptop is stolen the burglar could gain access to the remote systems.

References
http://www.mccambridge.org/…
http://www.tjansson.dk/?p=18 <- In danish on sshfs, encfs and FUSE.

This entry was posted in Articles, Computer. Bookmark the permalink.

46 Responses to Autofs and sshfs – the perfect couple

  1. Geoff says:

    [quote]If this done on a laptop and the laptop is stolen the burglar could gain access to the remote systems.[/quote]

    But if you knew the laptop had been stolen (likely), you would only need to generate a new id_rsa.pub key for the user. This would prevent access from the stolen laptop.

  2. Mickey says:

    A great combination. I have used sshfs a lot (usually with the –reconnect option), but never combined it with autofs. Also, thanks for introducing me to the ssh-copy-id command – I have done this process manually more times than I can count.
    One catch to watch for with sshfs – it always reports no space free on disk. If a program (such as gnucash) checks for this, it will think the disk is full and won’t save the file.
    You can stay out of /etc/passwd with the id command. id [username] will report uid, gid and supplemental groups.

  3. xiao_haozi says:

    “[quote]If this done on a laptop and the laptop is stolen the burglar could gain access to the remote systems.[/quote]

    But if you knew the laptop had been stolen (likely), you would only need to generate a new id_rsa.pub key for the user. This would prevent access from the stolen laptop.”

    You could also keep your key on a usb jump drive. Most likely this would get stolen too with the laptop, but hopefully the thief would not know that the usb drive serves that purpose. Might add another layer of security anyway. But Geoff’s idea is right on with changing the keys upon the even of a stolen machine.

  4. Jonathan says:

    [quote]If this done on a laptop and the laptop is stolen the burglar could gain access to the remote systems.[/quote]

    I don’t know much about anything, but if you set the permissions of the key correctly, then a burglar would have to have your user password before any damage could be done. Right? And a person with sensitive information should be smart enough not to leave their computer on and unlocked while they are away.

    Great post. It’s really well written for a newbie like myself. Thanks.

  5. helmingstay says:

    “root@bohr:~# ssh-keygen -t dsa”

    “If this done on a laptop and the laptop is stolen the burglar could gain access to the remote systems. ”

    The logical method is to create the key with a passphrase. No passphrase on a key doesn’t seem like the brightest idea. It gives not just access to the filesystem, but (AFAIK) the user account on the remote machine.

    I thought that ssh-agent and ssh-add would work via sshfs’s argument list. Alas, the agent is set up in the user’s environment, whereas autofs is running in it’s own daemon environment.

    It looks cool and feels cool – i really like the autofs timeout…

  6. helmingstay says:

    So, setting the timeout to 600 seems to work for me. Not sure what happens if the link goes down while it’s mounted – is autofs, sshfs, or both responsible for the graceful exit?

  7. Peter says:

    There is no graceful exit…

  8. Karneevor says:

    I’ve noticed that autofs for a user doesn’t work until root have exchange key with the remote server.

    That’s odd.

    Can any of you confirm that observation?

  9. I am afraid that it is so. In the version I have written it is not suited for a multiuser setup. I have not researched whether or not it possible to make a autofs in per-user setting. I find something please let me know – sounds like better solution.

  10. Oli says:

    Hi,
    I’m very fond of the idea having automounted remote drives.
    First: I think this line:
    root@bohr:~# ssh-keygen -t dsa
    needs to be
    root@bohr:~# ssh-keygen -t rsa

    Second: I don’t get this to work. sshfs works, login without password works, automount triggers, but in the middle it seems to hang itself up somewhere. I described my problem here http://ubuntuforums.org/showthread.php?p=5898893
    mabye you could have a look at it since nobody else there seems to be able to help.

  11. As for the RSA/DSA discussion I tried to research this morning and seem to find people on both sides of the fence although the putty team recommends RSA:
    http://the.earth.li/~sgtatham/putty/0.60/htmldoc/Chapter8.html#puttygen-keytype
    Could you post a link to some authoritative site?

    Just some questions for your problems. Are you sure that you pid is 1000 as i my example? Are you able to do a passwordless login from root on your local machine to the remote machine?

  12. Oli says:
    
    oli@Oli:~$ id
    uid=1000(oli) gid=1000(oli) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),46(plugdev),107(fuse),109(lpadmin),115(admin),1000(oli),1001(video)
    

    SSH login works with my user and also as root without password. And no matter if i switch to the directory that is supposed to automount as user or as root, the process i mentioned in that thread is spawned but it doesnt do anything and i just get the ‘No such file or directory’ message.

    I really can’t explain whats wrong, i set up everything exactly as you described (apart from the rsa key).
    Does automount log its actions somewhere? Theres nothing regarding this in the syslog.

  13. Seems real strange. One more question – does the directory “/home/oli/sshfs” exist? (I found this in your ubuntuforums.org post)?

    Automount does log failures in the /var/log/daemon.log – it could be interesting to see why it fails.

  14. Oli says:

    /home/oli/sshfs/ exists.
    When I switch to /home/oli/sshfs/gtv it logs into the daemon.log:

    
    Oct 12 15:01:42 Oli automount[12109]: lookup(program): lookup for gtv failed
    Oct 12 15:01:42 Oli automount[12109]: failed to mount /home/oli/sshfs/gtv
    

    does that mean it can’t find a rule for the “gtv” directory even though such a line is there in my auto.sshfs? The process mentioned first in my post still runs.
    Thanks for your help so far.

  15. “lookup(program): lookup for gtv failed” Sounds a bit like you tried to connect a host with a hostname not listed in your “/etc/hosts” file or cannot be found in DNS? Do sshfs fail for all hosts that you have tried? Could you test with a host on the inside of your network and maybe try to use a ip instead of hostname to rule out DNS?

  16. Oli says:

    Well,
    I don’t think thats the problem, mounting it manually with sshfs and that hostname works fine. Anyway, I tried to change the hostname to the actual ip with no effect (same behaviour anywhere).
    And since it sais “lookup for gtv failed”, not for the actual hostname “lookup for gamestv.org failed” I still think its something to do with the directive for the “gtv” mount, like it notices that it has instructions for /home/oli/sshfs, opens the corresponding file (/etc/auto.sshfs) to look for directives for the “gtv” directory, but then sais it fails because it cant find any instructions for that – though its there.
    I have no idea what else could cause this so unless you have any new ideas i think ill give up on this – as nice as it would be.

  17. Pingback: Configuring Isis « El diari de’n Xesc

  18. Pingback: Automount remote filesystem over SSH : David Laing’s blog

  19. Romain says:

    Thx body, your how-to was pretty useful to solve an issue i had with the public/private key.

  20. Recif says:

    Hi,
    Thanks for a useful how-to. Can sshfs be setup to do a multi-hop? I need to connect to targethost through gatewayhost.
    recif

  21. I don’t think it is possible from within sshfs but I guess you could setup autofs on the gateway or host as well? Alternatively you need to create some SSH tunnels through the gateway.

  22. Nitin DB says:

    I tried the above with success. However, I found browsing within the mounted sshfs folder to be painfully slow and often would lock-up if browsing a folder with plenty of files an images.

    I’m now using Nautilus to create an sftp connection which seems much faster while browsing. What could be the reason for this?

    Is sshfs with autofs much more dependent on bandwidth and net connection speed, than a plain sftp with Nautilus?

  23. The system is unaware that /mnt/autofs/foo is not a local filesystem. However the system will aware when mountet through gnome. This means the gnome will not try to create thumnails when using the built-in gnome SSH but will create thumbnails when using autofs.

  24. Erik says:

    how on earth is it possible to mount with a passphrase?

    passphraseless ssh keys are useless, I may as well store my password in plain text on the hard disk.

  25. Thomas says:

    Great article; it has been very useful to me, thanks!

    I’d like to mention that I added the sshfs option transform_symlinks to the options list. This transforms absolute symlinks in the mount to relative ones, so they still point to the same thing on the server.

  26. Sergey says:

    Thanks for the article!
    All things work in general, but setting up password-protected keys is a problem. Variables SSH_AGENT_PID and SSH_AUTH_SOCK should be set in sshfs’s environment. But it seems, that autofs launches mounter in clean env from root, so my personal ssh-agent is invisible for it. No ideas of how to connect them:) Maybe that ConsoleKit will help one day..

  27. Sergey says:

    No, wait, There IS a way to launch sshfs with passworded keys via automount!
    Look at http://pturing.firehead.org/software/autofs_sshfs
    Method uses workaround sudo_ssh scripts, but it works!

  28. Pingback: autofs+sshfs "Directory not found"

  29. Pingback: mount remote file systems via ssh « James Reid

  30. Nick J says:

    in modern Ubuntu, it’s “aptitude install fuse-utils” (note the extra dash).

  31. Almir says:

    Last thing to do – Restart the autofs deamon

    /etc/init.d/autofs restart

    And you will be able to change directory to /mnt/sshfs/bar (or your mount-point) seamlessly.

  32. Pingback: Using sshfs with autofs « 0ddn1x: tricks with *nix

  33. indium says:

    ROOT != SU !!!
    The mount via autofs+sshfs doesn’t work until you have added the ‘id_dsa.pub’ on the client side to the ‘authorized_keys’ on the server side, BUT:

    since autofs (running on the ‘client computer’) itself operates as user ‘root’, you have to get the client-side ‘root’ to be able connect password-less to the server side ‘user’ account. I used to test this by logging in with ‘su’ on the command line and then ‘ssh user@server’. This does NOT test your ability as ‘root@client’ to log in to the server, but as ‘username_on_client@client’!! Do NOT use ‘su’ to test the password-less connection but, instead, login to your ‘client’ (local computer) as user ‘root’, and _then_ try it again. You will probably find that you still have to type in a password. If so, make sure that /root/.ssh/id_dsa.pub is there (otherwise generate as on this webpage) and copy that to the server side ‘user@server:~/.ssh/authorized_keys’.

    ‘su’ is not 100% ‘root’ !!!

  34. Johan says:

    Thnx! Great article. And my problem was indeed fixed by generating and adding my root user key.

    For users that want to log in to their local machine but don’t have (and don’t want) a root password. You can use: $ sudo su -

  35. Ganesh says:

    For people who it is not working, just be careful with spaces. I missed a space before :sshfs and it blew very badly, also no spaces before or after commas

  36. RDuke says:

    The problem I have is that whenever I enter the sshfs directory with any file manager (Krusader, Nautilus), autofs will try to mount ALL servers defined in /etc/auto.sshfs, instead of waiting for me to cd to one of the servers.

    This automatic mount of all servers produces a long delay, aggravated by the fact that some of my servers are on private networks which are not accessible from my location.

    I’m sure there must be an option to prevent this useless pre-mounting, but I couldn’t find it.

  37. BUGHUNTER says:

    To overcome the problem that you have to be root to do this you might be interested in AFUSE:
    http://afuse.sourceforge.net/
    yes, this is a FUSE automounter :)

  38. Jake says:

    I know this is a really old post, but how would you add in sshfs options to this autofs implementation? I’m trying to add in:

    -o workaround=rename

    As described here:

    http://liquidat.wordpress.com/2008/08/10/short-tip-moving-files-on-sshfs-mounts/

    When using autofs, it isn’t clear where to add in this SSHFS option. Anyone have any ideas?

  39. Bob says:

    This is exactly what I needed. Thanks!

  40. -DC- says:

    Works initially, but then I start getting “transport endpoint is not connected” errors on my mount. Only way to recover is to unmount and let autofs remount. Not an ideal solution.

  41. Pingback: update bookmark blog 12/25/2012 (a.m.) | Kevin Mullet's Bookmarks

  42. Pingback: Sharedfolders mit libvirt und KVM « darkfirewave

  43. Pingback: SSHFS mount that survives disconnect - Just just easy answers

  44. Pingback: sshfs and autofs – The perfect marriage « Syntax Error

  45. Tobias says:

    The step…

    root@bohr:~# ssh-keygen -t dsa

    …is so dangerous. You should NEVER create private/public keys for root. Period. I’m sorry but if you do, you are giving ROOT access to the server to anyone who gets/steals the public key. The whole file system, all user’s data, virus insertion, etc, etc. No, no, no, no, no, no… Did I say “no” enough times?

    I think autofs is a great thing, but it needs to be improved to use a non-root account. With that feature it would be great.

  46. Wauv Tobias – such passion for a post that is 6 years, 9 months and 7 days old from today. You are completely right by the way, but so were commenters 6 years where we discussed this in the comments. :)

Leave a Reply