How about using ACLs (Access Control Lists) in this case? All the modern filesystems do support ACLs and with them you can grant access to individual directories/files more granularly than with traditional Unix permissions.
For starters, try man setfacl. It has several examples listed.
Since I had the same problem on CentOS, I was running with the assumption that ssh_command doesn't work as advertised (also meaning that it doesn't work the same as most other things that can hook into SSH -- rsync, for example). I began looking for ways that I could configure SSH to set the options I need without requiring for me to feed input from the command line to sshfs, and I found the combination that works.
I added to /etc/ssh/ssh_config the following lines:
Host remotehost
HostName 192.168.1.1
User user
IdentityFile /home/me/.ssh/myKey
After doing that, I no longer needed to feed any command line options to SSH through sshfs and ended up with this command:
sshfs user@remotehost:/remote/dir /local/dir
It should be noted that remotehost in the sshfs command is the exact value that was defined for the Host key in ssh_config.
If someone knows of a way to perform this task using command line options, I am still interested as I don't think that it's right that it should require a system-wide configuration change to make this work as the documentation claims. Until then, I at least have a work-around. I hope this helps someone else avoid the hours I spent on it.
FWIW, post 4 on this thread was the source of my inspiration. Post 5 looks promising as a way to be able to avoid altering the system-wide configuration, but that lead to the error execvp: Permission denied
Best Answer
Use
-o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3The combination
ServerAliveInterval=15,ServerAliveCountMax=3causes the I/O errors to pop out after one minute of network outage. This is important but largely undocumented. IfServerAliveIntervaloption is left at default (so without the alive check), processes which experience I/O hang seem to sleep indefinitely, even after the sshfs getsreconnect'ed. I regard this a useless behavior.In other words what happens on
-o reconnectwithout assigningServerAliveIntervalis that any I/O will either succeed, or hang the application indefinitely if the ssh reconnects underneath. A typical application becomes entirely hung as a result. If you'd wish to allow I/O to return an error and resume the application, you needServerAliveInterval=1or greater.The
ServerAliveCountMax=3is the default anyway, but I like to specify it for readability.