WikiDevi.Wi-Cat.RU:DD-WRT/Sshfs
Introduction
Sshfs is a Network File System, like NFS or Samba. From the Wikipedia:
SSHFS (Secure SHell FileSystem) is a file system for Linux (and other operating systems with a FUSE implementation, such as Mac OS X or FreeBSD) capable of operating on files on a remote computer using just a secure shell login on the remote computer. On the local computer where the SSHFS is mounted, the implementation makes use of the FUSE (Filesystem in Userspace) kernel module. The practical effect of this is that the end user can seamlessly interact with remote files being securely served over SSH just as if they were local files on his/her computer. On the remote computer the SFTP subsystem of SSH is used.
Requirements
Since Dropbear (the default ssh server) apparently does not support sshfs, you will need to install and run Openssh instead. This in turn requires Optware. Obviously you should have a drive attached to your router to have something to share, so a router with a usb port is necessary.
Note from Manuel: I managed to use sshfs with the default ssh by installing the "openssh-sftp-server" package and passing the path to the sftp-server as command-line option "-o sftp_server=/opt/libexec/sftp-server" to sshfs.
Advantages and disadvantages
Compared to more common networked file systems like NFS and Samba, sshfs is more restricted in scope, especially in terms of restricting access: To gain access you'll need to have an account and a password on the server and you'll then have whatever access that the user on the server has when ssh'ing into the box. Since most DD-WRT users will likely only have the root account, this makes sshfs more useable for single-user setups. Also, be aware that Openssh is a lot more memory hungry than dropbear, so check 'top' if you're running other memory intensive programs at the same time.
The advantages of sshfs over NFS and Samba are a repsonsiveness much closer to local file systems than either of the common systems and somewhat faster transfer speeds (your mileage may vary). Also it has (at least for me) proven very stable with no outtages yet. The simplicity of sshfs setup can also be an advantage if you do not actually have a use for Samba's bewildering array of configuration options. If you know how to use SSH, you know how to use sshfs.
How-to
First, we'll install openssh:
/opt/bin/ipkg-opt install openssh
In order to avoid conflicts over port 22 (default ssh), we'll need to stop dropbear first. We'll use the web interface. If you're currently ssh'ed into the box, log out. Under 'Services' disable SSHd and enable telnet, save and apply settings. Now, telnet into the box
telnet 192.168.1.1
and start Openssh:
/opt/etc/init.d/S40sshd
We'll log out now and attempt a mount from the local machine. Be sure to have an sshfs package installed (on my Arch Linux installation it is simply installing 'sshfs') and to make a local mount point. In this example, I have mounted the attached WD MyBook 500 Gb drive on /mnt on the router (called SAM - you can use 192.168.1.1 instead). This directory will in turn be mounted on /mnt/mack on my laptop:
sshfs <user>@<host name | host ip>:/<directory on router> <local mount point> sshfs root@SAM:/mnt /mnt/mack
You will be queried for your password (if you don't already have some sort of autologin) and the directory should be available to you on your local mount point.
In an fstab setup, the same action looks like this:
sshfs#root@SAM:/mnt /mnt/mack fuse user,auto,noatime,allow_other 0 0
Note that the "sshfs#" is not a comment but a way of telling fstab what kind of file system it is. If you do not use allow_other your reqular user will not even be able to see the mount point, let alone browse it.
In order for an fstab entry to work you will need to setup ssh autologin for your local root user (since it will be the root user doing the mounting). See http://magicmonster.com/kb/net/ssh/auto_login.html for info on how to do that. Unlike most other network file systems, sshfs doesn't appear to have a way of passing password info in options.
And that's it. No more mucking about with NFS exports and smb.conf files. Your regular local user will now have root user privileges over the mount so copying, deleting and moving files is as easy as in your home directory. Enjoy.
Hints & Caveats
If the sftp subsystem is not working, saying "subsystem request failed on channel 0" while trying to mount a directory via sshfs. There is a misconfiguration preventing the loading of an external sftp server or no module can be found on the specified router.
To circumvent this situation, you can use the in-process sftp-server by changing the sshd configuration file named "sshd_config" located in "/jffs/opt/etc/openssh".
cd /jffs/opt/etc/openssh vi sshd_config
Search for the line Subsystem comment out the external sftp-server entry and create a new one using the internal-sftp instead.
#Subsystem sftp /opt/libexec/sftp-server Subsystem sftp internal-sftp
Save the file with :x, reboot and try a sshfs mount to ensure system is working properly.
