“The goal of this howto is building a NFS server that works on an SSH tunnel. This way all traffic between your hosts and the file server is encrypted and thus more secure. Normally you should enter a password every time you try to establish a SSH connection but since we could be mounting at bootup we will use ssh-keygen to create a keypair so we can login without entering a password. We will, however, limit that login session to executing just 1 command.”
Thats a very nice way to secure NFS services but on a highload network how its going to perform?
This howto could really be better :
1. It could have set fixed port number on the server. This way even after a restart, there should have no issue.
2. instead of SSH tunneling ( which need a user auth ), it could have use stunnel to do a SSL tunneling between the nfs client and the nfs server.
http://www.stunnel.org/
Why do this when all it does it provide transport protection. It doesn’t actually help with NFS authentication of end points.
NFS can already be secured using Kerberos, and whats more NFSv4 mandates it be implemented.
This seems like good information, although SSH is being pressed into service as a VPN.
I already use NFS over an OpenVPN (http://openvpn.net/) connection. I believe it uses the same OpenSSL library as OpenSSH, so presumably the security should be similar. But OpenVPN gives me a more general VPN connection which is useful for other applications also.
@darkmind:
i just updated the howto with fixed ports, thnx for mentioning the issue Should have done that right from the start
NFS still has no built in encyrption?
If using Linux why not just use FUSE with SSH-FS mounts?
There are stacks of ways to do the same thing here. The article is just a howto on one solution.
I have always tried to use NFS instead of SMB/CIFS and the others seeing as I am in a pure $nix network. But I would say the final straw was the strange problem I had where NFS would not allow the viewing of files and folders on server that were on a mounted filesystem off the exported tree. Eg. export /home/user. /home/user/other is a mounted fs (/dev/hdg1). From the client I can’t see files in /home/user/other. Bizzar. SMB/CIFS can. I use CIFS everywhere now because it is easy to set up (easy to configure, PITA to install). All other network file systems are overkill to use in a small network. If I need secure remote access I use either hamachi or openvpn.
I would recommend to use http://www.fs.net/ on WAN.
Probably a better solution is to set the shared user account shell to /bin/false, then construct the tunnel with the ssh -N option (which will put the ssh session in tunnel only mode, thereby not calling to shell, which will, as desired, fail with /bin/false as the shell).
This way the shared account is more controlled beyond just ssh sessions.
Bert