I have a NAS (Netgear Readynas NV+) at home and a linux (Arch) box at work that is always on. The linux box is already running an ssh server/daemon and the NAS is already running an rsync server/daemon. The NAS does not support rsync over ssh. The way I understand it is I can either enable port forwarding on my home router to enable my linux box to initiate an rsync with the NAS or I can enable an rsync server on the linux box and allow the NAS to initiate the sync. Since my home router does not have a static ip address, I am leaning towards running an rsync server on the linux box.

Is one way more secure than another? Are there major security drawbacks to doing either?

  • In what way "secure"? Are you fearing a break-in at work, at home or a man-in-the middle that copies your data? – Nils Dec 1 '12 at 22:16
  • @Nils I am not worried about the data that is being backed up as it is not confidential/private. I want to prevent my work machine and home network from being compromised. My work machine and home network have confidential and private data on them. The confidential data on the home network is not stored on the NAS. – StrongBad Dec 4 '12 at 11:52

Go with what's already setup, if ssh on the work box is already an open/monitored/supported/audited service then try to do the rsync via that. Not opening up new ports/services is generally safest. Not opening up insecure protocols to the internet is even better =)

You can get ssh access to the ReadyNas (if you don't mind some hassle from Netgear in the event of a "i deleted my nas" support call). Then rsync -e ssh from the command line which leaves nothing else to setup. Auth, wire security and user/file permissions are all provided by ssh/remote shell setup on work box.

For opening up ssh on your home network:

  • The dynamic IP hassles can be covered by running a free dynamic DNS service.

  • Restrict access to the port to your work box's public IP.
    Some routers allow you to set a source IP in the NAT rule.
    SSH can be secured with iptables and more

As DarkHeart mentioned, rsync by itself over an unsecure network is not a good idea. The tunnel and vpn mentioned is a good work around. You can keep the aforementioned ssh tunnel up with autossh. You may want to depend on some rsync security if your going to leave a tunnel up depending on who else has access to either end.

Also, if you haven't already, discuss what your doing with someone. Detail what data is going in/out of the network. Think about what data might be able to go out if everything goes wrong. Document your process somewhere.

  • You are correct that the ReadyNas does "support" ssh. It is the nice gui backup system that I was hoping to use that doesn't support rsync over ssh. – StrongBad Dec 4 '12 at 12:01
  • To use the GUI, and be secure, you need a local box you can ssh to or from and an rsync server running at work. You could use the ssh access to the NAS for just the tunnel. Similar to DarkHeart's answer ssh WORKBOX -L 874:localhost:873 (see autossh too). Once you have an rsync server up and configured at work and the ssh tunnel is up, you should be able to point the GUI at a "remote" server of localhost:874 and it will rsync with your work box. – Matt Dec 5 '12 at 14:13

Rsync, by itself, transmits data in clear-text. So either way is going to be insecure. You either need to use SSH tunnelling or setup a VPN. If you have no SSH access to the NAS at all, you could use a third server at 'home' to tunnel from one to the other. eg:


Otherwise use your work computer to log into your home VPN.

To answer your question: I would say that if you can avoid opening up ports then that would be more secure.

  • Does rsync transmit authentication data in the clear also? Can one gain access to the entire system via the rsync daemon? – StrongBad Dec 4 '12 at 11:54
  • The rsync protocol does not encrypt auth. You can gain access to the configured areas (example down the bottom of the page) short of a security issue in the rsync deamon, of course. Note that auth is via a rsync secrets file. – Matt Dec 5 '12 at 13:33

Your scenario is difficult. Normally it is no problem to open a connection from a low-threat-zone towards a high-threat-zone (i.e from an internal network towards a dmz) - the system that is more in the danger of being compromised is the one with open services/ports towards the internet (this is only true for automated transfers - since we all know that we can be attacked through our web-client-connections).

I would say that the work-machine should open a connection towards your home-machine (I hope this is legal at your work) - and use a technique called port-knocking on your home-machine. The sequence to open the target-port on your home-machine has to be stored on your work-machine. AND you should change that sequence after each use.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.