NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
jhaye1
Oct 16, 2013Aspirant
RSYNC over SSH backup using a different port - OS 6.1.2
Hi There My environment: ReadyNAS RN102 OS: 6.1.2 My goal: Have an RSYNC-over-SSH backup job configured and running on my ReadyNAS, towards an RSYNC server that uses another port tha...
jhaye1
Feb 11, 2014Aspirant
Indeed I have tried playing around with SQLite. The following brings you into the SQL DB and shows (the only one, in my case) backup job configured:
root@nas-TEST:~# sqlite3 /var/readynasd/db.sq3
SQLite version 3.7.17 2013-05-20 00:56:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .header ON
sqlite> select * from backup;
id|name|enabled|sch_every|sch_start|sch_end|sch_dow|src_type|src_share_proto|src_path|src_login|src_password|src_port|src_eject|dst_type|dst_share_proto|dst_path|dst_login|dst_password|dst_port|dst_eject|opt_full_backup_freq|opt_remove_previous_backup|opt_chown_to_share_owner|opt_rsync_options|opt_email_this_to_alert_email|opt_rsync_exclude|opt_misc_option|wol_addr
1|test-backup|0|24|0|23|127|share|Documents||||0|0|remote|rsync+ssh|rbackup.mydomain.be:/|||0|0|FIRST_TIME|0|0|0|1||0|
sqlite>
I assume that the value "0" set to "dst_port" field (shown in red) means "use the default SSH port i.e. 22. I then do:
sqlite> update backup set dst_port=2222;
sqlite>
then chech the table update:
sqlite> select * from backup;
id|name|enabled|sch_every|sch_start|sch_end|sch_dow|src_type|src_share_proto|src_path|src_login|src_password|src_port|src_eject|dst_type|dst_share_proto|dst_path|dst_login|dst_password|dst_port|dst_eject|opt_full_backup_freq|opt_remove_previous_backup|opt_chown_to_share_owner|opt_rsync_options|opt_email_this_to_alert_email|opt_rsync_exclude|opt_misc_option|wol_addr
1|test-backup|0|24|0|23|127|share|Documents||||0|0|remote|rsync+ssh|rbackup.mydomain.be:/|||2222|0|FIRST_TIME|0|0|0|1||0|
sqlite>
The dst_port has been properly changed, however, a TCPDUMP reveals that when launched, the backup job still uses the default port 22 (SSH). I then have restarted the backup manager process (" systemctl restart fvbackup-q" ), which didn't have help, although the dst8port was still set to 2222.
Note that any edition of the backup job settings from FrontView will set this parameter back to "0".
Considering the amount of Internet attack tentatives I see on port 22 towards my RSYNC remote backup server (fortuantely I have set a very strong password), it's critical to have the ability to set the destination port, ideally within frontview interface.
Note that my RSYNC backup server is also a ReadyNAS (RN104) runing OS6, thus FAIL2BAN doesn't seem to be an option, unfortunately.
Jean-Marc
PS 1: I'm running 6.1.6 right now (i.e. the latest available firmware)
PS 2: I can confirm that since 6.1.4 you can specify an FQDN for destination :D
root@nas-TEST:~# sqlite3 /var/readynasd/db.sq3
SQLite version 3.7.17 2013-05-20 00:56:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .header ON
sqlite> select * from backup;
id|name|enabled|sch_every|sch_start|sch_end|sch_dow|src_type|src_share_proto|src_path|src_login|src_password|src_port|src_eject|dst_type|dst_share_proto|dst_path|dst_login|dst_password|dst_port|dst_eject|opt_full_backup_freq|opt_remove_previous_backup|opt_chown_to_share_owner|opt_rsync_options|opt_email_this_to_alert_email|opt_rsync_exclude|opt_misc_option|wol_addr
1|test-backup|0|24|0|23|127|share|Documents||||0|0|remote|rsync+ssh|rbackup.mydomain.be:/|||0|0|FIRST_TIME|0|0|0|1||0|
sqlite>
I assume that the value "0" set to "dst_port" field (shown in red) means "use the default SSH port i.e. 22. I then do:
sqlite> update backup set dst_port=2222;
sqlite>
then chech the table update:
sqlite> select * from backup;
id|name|enabled|sch_every|sch_start|sch_end|sch_dow|src_type|src_share_proto|src_path|src_login|src_password|src_port|src_eject|dst_type|dst_share_proto|dst_path|dst_login|dst_password|dst_port|dst_eject|opt_full_backup_freq|opt_remove_previous_backup|opt_chown_to_share_owner|opt_rsync_options|opt_email_this_to_alert_email|opt_rsync_exclude|opt_misc_option|wol_addr
1|test-backup|0|24|0|23|127|share|Documents||||0|0|remote|rsync+ssh|rbackup.mydomain.be:/|||2222|0|FIRST_TIME|0|0|0|1||0|
sqlite>
The dst_port has been properly changed, however, a TCPDUMP reveals that when launched, the backup job still uses the default port 22 (SSH). I then have restarted the backup manager process (" systemctl restart fvbackup-q" ), which didn't have help, although the dst8port was still set to 2222.
Note that any edition of the backup job settings from FrontView will set this parameter back to "0".
Considering the amount of Internet attack tentatives I see on port 22 towards my RSYNC remote backup server (fortuantely I have set a very strong password), it's critical to have the ability to set the destination port, ideally within frontview interface.
Note that my RSYNC backup server is also a ReadyNAS (RN104) runing OS6, thus FAIL2BAN doesn't seem to be an option, unfortunately.
Jean-Marc
PS 1: I'm running 6.1.6 right now (i.e. the latest available firmware)
PS 2: I can confirm that since 6.1.4 you can specify an FQDN for destination :D
Related Content
NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!