Comments on [Debian-Sarge] Tunneling NFS over SSH

Thank you. I was attempting to have my home server perpetually mounted onto a roaming laptop. Sshfs was insufficient for the task at hand, and this was exactly what I was looking for.

While this is all useful information, it's quite complex to set up. There's much easier solution if you want secure (encrypted) remote file access and it's called sshfs. Quick and simple setup, you'll find it useful, I'm sure.

I would advise using the -N option of recent ssh versions to keep the connection open without running a command.
With this option you can set the sleeper user's shell to /bin/false. Thereby restricting command execution even further.

Another great util for this setup is autossh, which automatically reconnects ssh after a connection is lost.

I agree with comments that this is a bit too involved and that sshfs makes a great alternative for a remote solution.

Claiming that sshfs is more useful is inaccurate and IMHO not a way to thank the author of this excellent HOWTO.

Try, as root,

# mknod foo c 1 3

in a sshfs-mounted directory before you say that sshfs is "more useful".

That being said, I love sshfs when operating on ordinary files.

In the log I was seeing....

refused mount request from 127.0.0.1 for /export/data (/export/data): illegal port 33146

I fixed this by adding "insecure" into the /etc/exports argument list...

/home/export/data 127.0.0.1(rw,root_squash,sync,insecure)

Note I bound it to localhost (127.0.0.1) because this share was strictly for piping there was no local area network.

Thanks TheFatherMind for that additional hint. On Lenny, "insecure" is needed.

You can read the details here: http://www.tldp.org/HOWTO/NFS-HOWTO/security.html#NFS-SSH
The short version is that doing this any user that is able to connect to the server with ssh can tunnel NFS to a computer where she/he has root permissions, and from there she/he can access the exported filesystem spoofing UIDs/GIDs and overcoming permissions.

     ssh [email protected] -L 250:localhost:2049  -f sleep 60m

   ssh [email protected] -L 251:localhost:32767 -f sleep 60m

In this page, they are using:

ssh -f -i /root/.ssh/id_rsa -c blowfish -L 62001:10.0.0.241:2233 -l sleeper 10.0.0.241 sleep 600d 

 The difference I'm pointing out is that in the above commands the ssh tunnels are logging into the server as root, while in the latter ones they are doing it as the very restricted user "sleeper".

So in the second case the privileges you have on the shares are limited to what sleeper can do even if you are root on the client. (And yes, I have tested this).

After following the above howto, something like this may be more suitable for everyday use

 FSTAB Entry:

localhost:/ /mount/directory nfs4 retrans=3,timeo=250,retry=0,soft,tcp,rsize=8192,wsize=8192,rw,fg,port=61001,mountport=62001,noauto

 Mount Command:

kdesu -c "ssh user@machine -i /path/to/keyfile -c aes256-cbc -f -o ExitOnForwardFailure=yes -L 61001:127.0.0.1:2049 -L 62001:127.0.0.1:2233 -N ; mount /mount/directory 2>&1 | xmessage -file -"

UnMount Command:

kdesu -c "umount -f /mount/directory ; sleep 0.1 ; umount -f /mount/directory ; sleep 0.1 ; umount -f /mount/directory ; sleep 0.4 ; umount -f /mount/directory ; sleep 0.1 ;  umount -f -l /mount/directory | xmessage -file -"

in my case i had to use