Accessing your data safely from around the globe
© 2012 Dennis Leeuw dleeuw at made-it dot com
License: GPLv2 or later
An SSHFS server is actualy and SFTP server. Like CIFS it is FTP over a single port (22), but with SSHFS you have the additional benefit of a secure (encrypted) link between you and the server.
The sftp-server component of the OpenSSH project is not meant to be used as a standalone SFTP server, but needs to be called from the sshd server, like a plugin.
To enable the SFTP server in SSH add the following line to your /etc/ssh/sshd_config file:
Subsystem sftp /usr/libexec/openssh/sftp-server
Most of the time this is all there is to it. If you want to provide everything in read-only mode, you can add the -R option like this:
Subsystem sftp /usr/libexec/openssh/sftp-server -R
The sftp-server subsystem "exports" the entire root to the network. Users that are able to log in to your server have locally the same rights as they have over the SSHFS link. Of course it is best to mount on a remote system only the part(s) that is really meaningful, like /home/<username>, however there is nothing preventing the user from mounting / on their system.
Of course this is not entirely true, there is a way to limit your user access by using a chroot-jail, however the downside is that the users home directory setting in /etc/passwd or LDAP must be changed to a path for the chrooted home. Meaning that in every home directory one should install the binaries needed for a chrooted-jail. For now that is beyond the scope of this document. For a good description and a script see the following pages:
Installation of sshfs on GNU/linux is distribution dependent. For Red Hat based systems use:
yum install fuse-sshfs
For Debian based systems use:
apt-get install sshfs
To mount a remote filesystem use:
sshfs -o idmap=user <username>@<your.server>:</path/on/server> </path/to/mount-point>
The -o idmap=user will map your local user name to the user name used in the mount part. Files on the remote system that are from the user username, appear to be from the user that you are logged in as on the local system. Even so when you create a file. It appears to be owned by the local user, but on the remote system it is owned by the remote user. Group IDs and other user IDs will not be mapped or mapped to IDs from the local system and thus have no real meaning. This is a cosmetic problem, all actions done on the remote machine are done with the rights of the user you used in <username>.
You can unmount the file system by using:
fusermount -u </path/to/mount-point>
To add it do /etc/fstab use:
sshfs#<username>@@<your.server>:</path/on/server> </path/to/mount-point> fuse defaults,idmap=user 0 0
When one wants to use SSHFS on the Mac using a graphical interface install:
The default implementation of SSHFS-support on Mac OS X uses an access check on the localy mounted share. This means that only local filesystem attributes are take into consideration for deciding if you have access to a certain file, which means that Linux ACLs are not considered when accessing a file. To overcome this MacFusion needs to be told to make the remote system responsible for checking access. In de Advanced settings add:
-o defer_permissions
For more options one could use see:
To be able to connect with SSHFS without being administrator one should use Win-SSHFS.
After the installation do:
Keep in mind not to use a driveletter that is already in use.