NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
ReadyNAS rsync backup to offsite QNAP over SSH fail
Hope this is the right place to post this - apologies in advance if not.
I'm currently testing rsync backups from my ReadyNAS Pro Business Edition running Raidiator 4.2.5 on my LAN to a QNAP TS-469 Pro. All works exactly as expected, no issues at all, until I try to add in tunnelling over SSH. When this is added the job fails, and in the QNAP logs I see an ssh login followed by a logout approx 1 second later.
I've read extensively around the subject, for what seems to be a simple procedure, but it's not working here. I am able to ssh into the QNAP to look around, but my client's ReadyNAS remains a closed unit - I'm reluctant to install EnableRootSSH, but might be forced down this road.
The ReadyNAS, configured to connect using rsync to the QNAP with an rsync username password/pair defined on the QNAP, works fine. It's when I try to tunnel over SSH that it fails: testing connection from Frontview gives the standard error: Error connecting to <IP address>/<rsync_share>.
I generated a public SSH key file in Frontview - and installed it on the QNAP via FTP in /etc/config/ssh/authorized_keys as detailed in "http://wiki.qnap.com/wiki/How_To_Set_Up_Authorized_Keys".
I've chmoded the file 600, 755 (read it need to be executable by others somewhere - clutching at straws here), but I've put it back to the default 644.
The authorized_key file finishes with the string " .... root@nas-EA-12-99", which matches my ReadyNAS's hardware address, so it looks fine at first glance. I'm aware that we're tunnelling, so that the 'root' user here not matching the QNAP's permitted rsync username (=admin) is irrelevant. It's the initial connection as root that appears to be the issue. Interestingly there's no user 'root' on the QNAP, just 'admin', which reading around seems like the QNAP's root equivalent. No home directory for either user on the QNAP:
[/etc/config/ssh] # pwd
/etc/config/ssh
[/etc/config/ssh] # ls -ltr
-rw-r--r-- 1 admin administ 397 Apr 26 01:22 ssh_host_rsa_key.pub
-rw------- 1 admin administ 1675 Apr 26 01:22 ssh_host_rsa_key
-rw-r--r-- 1 admin administ 605 Apr 26 01:22 ssh_host_dsa_key.pub
-rw------- 1 admin administ 668 Apr 26 01:22 ssh_host_dsa_key
lrwxrwxrwx 1 admin administ 20 Apr 26 01:24 id_rsa.pub -> ssh_host_rsa_key.pub
lrwxrwxrwx 1 admin administ 16 Apr 26 01:24 id_rsa -> ssh_host_rsa_key
-rw-r--r-- 1 admin administ 391 Sep 13 12:10 known_hosts
-rw-r--r-- 1 admin administ 399 Sep 13 13:44 authorized_keys
Has anyone had any experience with this? It's driving me insane, and whilst local LAN backups are fine for testing, the QNAP needs to go off-site and data sent over SSH as a DR solution.
Many thanks in advance.
I'm currently testing rsync backups from my ReadyNAS Pro Business Edition running Raidiator 4.2.5 on my LAN to a QNAP TS-469 Pro. All works exactly as expected, no issues at all, until I try to add in tunnelling over SSH. When this is added the job fails, and in the QNAP logs I see an ssh login followed by a logout approx 1 second later.
I've read extensively around the subject, for what seems to be a simple procedure, but it's not working here. I am able to ssh into the QNAP to look around, but my client's ReadyNAS remains a closed unit - I'm reluctant to install EnableRootSSH, but might be forced down this road.
The ReadyNAS, configured to connect using rsync to the QNAP with an rsync username password/pair defined on the QNAP, works fine. It's when I try to tunnel over SSH that it fails: testing connection from Frontview gives the standard error: Error connecting to <IP address>/<rsync_share>.
I generated a public SSH key file in Frontview - and installed it on the QNAP via FTP in /etc/config/ssh/authorized_keys as detailed in "http://wiki.qnap.com/wiki/How_To_Set_Up_Authorized_Keys".
I've chmoded the file 600, 755 (read it need to be executable by others somewhere - clutching at straws here), but I've put it back to the default 644.
The authorized_key file finishes with the string " .... root@nas-EA-12-99", which matches my ReadyNAS's hardware address, so it looks fine at first glance. I'm aware that we're tunnelling, so that the 'root' user here not matching the QNAP's permitted rsync username (=admin) is irrelevant. It's the initial connection as root that appears to be the issue. Interestingly there's no user 'root' on the QNAP, just 'admin', which reading around seems like the QNAP's root equivalent. No home directory for either user on the QNAP:
[/etc/config/ssh] # pwd
/etc/config/ssh
[/etc/config/ssh] # ls -ltr
-rw-r--r-- 1 admin administ 397 Apr 26 01:22 ssh_host_rsa_key.pub
-rw------- 1 admin administ 1675 Apr 26 01:22 ssh_host_rsa_key
-rw-r--r-- 1 admin administ 605 Apr 26 01:22 ssh_host_dsa_key.pub
-rw------- 1 admin administ 668 Apr 26 01:22 ssh_host_dsa_key
lrwxrwxrwx 1 admin administ 20 Apr 26 01:24 id_rsa.pub -> ssh_host_rsa_key.pub
lrwxrwxrwx 1 admin administ 16 Apr 26 01:24 id_rsa -> ssh_host_rsa_key
-rw-r--r-- 1 admin administ 391 Sep 13 12:10 known_hosts
-rw-r--r-- 1 admin administ 399 Sep 13 13:44 authorized_keys
Has anyone had any experience with this? It's driving me insane, and whilst local LAN backups are fine for testing, the QNAP needs to go off-site and data sent over SSH as a DR solution.
Many thanks in advance.
2 Replies
Replies have been turned off for this discussion
- I'm imagining I might be sitting behind a standard dialogue on the ReadyNAS prompting me to add the ReadyNAS to the QNAP's /etc/config/ssh/known_hosts file, but clearly I'm not connecting with a shell, instead doing all this through Frontview on my client's closed ReadyNAS. Does this help debugging?
Again, cheers for any help. BTW, the SSH key on the QNAP was created with cat public_ssh_key.txt >> authorized_keys, FTP'd over from a Windows 8 machine from the command line, ascii mode. - Further info:
I followed the instructions in: http://kb.netgear.com/app/answers/detail/a_id/12263/~/setting-up-rsync-over-ssh
I also tried manually editing the /etc/config/ssh/known_hosts file, and putting my IP address at the front. Still no joy.
Also every permutation of user (admin, root) and their login and rsync passwords ...
I'm feeling rather dim - from the docs this looked like to was going to be a 10-minute job once I'd recommended it as a DR solution to my client.
Thanks again.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
