NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
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 than the standard port 22:
Remote server IP: 128.203.202.1 (fake address)
Remote server SSH port: 30023
My challenge:
The remote RSYNC server is behind a firewall. I have thus configured a port forwarding on my firewall as follows:
my_wan-IP, port 30023 --> my_lan_rsync_server, port 22
For various reasons, it is out of the question to have port 22 facing the internet. That's why I'm forwarding from port 30023 to port 22.
Unfortunately, there seems to have no way to tell frontview to use a different SSH port that 22, when it relates to RSYNC over SSH.
What I have tried:
- From FrontView:
I have set the destination host field to "128.203.202.1:30023" (assuming that 128.203.202.1 is my remote firewall public address), in order to force SSH session over port 30023
=> When I click on "Test connection" button, I can verify with TCPdump that my outgoing packets are indeed send over TCP port 30023 :D
=> But when I click on "Apply" then Frontview reports an error, because it doesn't interprete my destition host field as a valid IP address :cry:
- From CLI console:
I have edited the file /etc/ssh/ssh_config (i.e. SSH client configuration file) on my ReadyNAS, and added the following lines at the top of the file:
Host 128.202.202.1
Port 30023
This way I want to force any SSH session toward 128.203.202.1 to use port 30023. Now I can set the destition host to "128.203.202.1" and nothing else, and make FrontView happy.
=> When I click on "Test connection" button, outgoing traffic goes again over port 30023 :D
=> I can now apply my settings, with no more complaints from FrontView 8)
=> But when I run my backup job manually, it just doesn't care about my SSH client config and thus uses port 22 :evil:
- I have also tried to locate the Frontview backup job script (as suggested in post http://www.readynas.com/forum/viewtopic.php?f=31&t=19857&p=118320&hilit=readynasexclude+rsync#p118320 ), but it looks like this was applicable to ReadyNAS running Radiator, and not to OS 6.
Thus Im stuck at the moment, so I have temporarily open internet facing port 22 on my distant firewall to workaround this. But it is not a long term solution for me ...
Any possible help from one of you guys ? I cant' believe that I'm the only one to face this issue.
PS: BTW, FrontView does not like a FQDN name either, and really wants a real IP address instead :roll:
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 than the standard port 22:
Remote server IP: 128.203.202.1 (fake address)
Remote server SSH port: 30023
My challenge:
The remote RSYNC server is behind a firewall. I have thus configured a port forwarding on my firewall as follows:
my_wan-IP, port 30023 --> my_lan_rsync_server, port 22
For various reasons, it is out of the question to have port 22 facing the internet. That's why I'm forwarding from port 30023 to port 22.
Unfortunately, there seems to have no way to tell frontview to use a different SSH port that 22, when it relates to RSYNC over SSH.
What I have tried:
- From FrontView:
I have set the destination host field to "128.203.202.1:30023" (assuming that 128.203.202.1 is my remote firewall public address), in order to force SSH session over port 30023
=> When I click on "Test connection" button, I can verify with TCPdump that my outgoing packets are indeed send over TCP port 30023 :D
=> But when I click on "Apply" then Frontview reports an error, because it doesn't interprete my destition host field as a valid IP address :cry:
- From CLI console:
I have edited the file /etc/ssh/ssh_config (i.e. SSH client configuration file) on my ReadyNAS, and added the following lines at the top of the file:
Host 128.202.202.1
Port 30023
This way I want to force any SSH session toward 128.203.202.1 to use port 30023. Now I can set the destition host to "128.203.202.1" and nothing else, and make FrontView happy.
=> When I click on "Test connection" button, outgoing traffic goes again over port 30023 :D
=> I can now apply my settings, with no more complaints from FrontView 8)
=> But when I run my backup job manually, it just doesn't care about my SSH client config and thus uses port 22 :evil:
- I have also tried to locate the Frontview backup job script (as suggested in post http://www.readynas.com/forum/viewtopic.php?f=31&t=19857&p=118320&hilit=readynasexclude+rsync#p118320 ), but it looks like this was applicable to ReadyNAS running Radiator, and not to OS 6.
Thus Im stuck at the moment, so I have temporarily open internet facing port 22 on my distant firewall to workaround this. But it is not a long term solution for me ...
Any possible help from one of you guys ? I cant' believe that I'm the only one to face this issue.
PS: BTW, FrontView does not like a FQDN name either, and really wants a real IP address instead :roll:
14 Replies
Replies have been turned off for this discussion
FrontView does not like a FQDN name either, and really wants a real IP address instead
6.1.4 RC1 allows FQDN hostnames now: viewtopic.php?f=154&t=72282- The backend code allows it to specify a port, but it seems the GUI does not expose that option at this point. Maybe future release...
# strings /frontview/bin/fvbackup
[...]
--rsh='ssh -o StrictHostKeyChecking=no -o PasswordAuthentication=no -p %d'
[...] - If you are good with SQL(lite), you can try changing the port in the database itself, there is a field for it.
# 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> .headers 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|1|24|21|23|62|share|backup|directory|||0|0|remote|rsync+ssh|128.203.202.1://remote/path|root||0|0|FIRST_TIME|0|0|2|0||0| chirpa wrote: If you are good with SQL(lite), you can try changing the port in the database itself, there is a field for it. # 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> .headers 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|1|24|21|23|62|share|backup|directory|||0|0|remote|rsync+ssh|128.203.202.1://remote/path|root||0|0|FIRST_TIME|0|0|2|0||0|
I edited my sqlite to the appropriate port, but it seems my RN102 still wants to connect on the default port. Is there a way to edit the file that provides the rsync command? I wouldn't mind hard coding in a new port for all remote rsync activities.- 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 - It's been over a year now. Any news on implementing this pretty trivial, but essential, feature?
- I had open a ticket to Netgear support about this, back more than 2 months ago. They told me that an enhancement request as been pushed for this, and then closed my case. Without any substancial news since then, I have open yet another ticket for the same thing this week (case #23112668). The answer I got is: "Level-3 support engineers have confirmed that the enhancement request does exist, at this point. It is possible that it will make it with the next major release, i.e. 6.2, although no guaranty of any sort. 6.2 is scheduled for the course of this year".
Well, in other words, it sounds like there not a single mile progression on this :cry: :evil: :twisted:
Jean-Marc - Thanks for opening the ticket. Let's hope they get around to adding this.
- Thanks to all who posted in this thread - this is exactly the same issue I was having; couldn't figure out why "test connection" worked fine but then after clicking "OK" it would fail.
I discovered something interesting (this doesn't help change the port but could be a potential workaround in certain cases). In my case I am trying to rsync to back up a remote directory on an Ubuntu 12.04 system running the csf/lfd firewall. Apparently with the CSF firewall, if you add an IP to the whitelist (csf.allow) then ALL ports can be accessed from that IP (even those that are not opened in the firewall). So you can add your home IP to the whitelist, open up port 22 in sshd_config, and the firewall will allow traffic on 22 from the whitelisted IPs while still blocking from everywhere else. So you'll still be able to hide port 22 from unknown IPs, which helps reduce the failed bruteforce attempts in the logs, but rsync from the ReadyNAS will work.
Ideally I'd still like a way to just specify my "preferred" SSH port directly in the web admin of the readyNAS, but this will work for now as my home IP almost never changes. I don't mind allowing sshd to listen on 22 as long as only a couple of IPs are allowed to see that port, and I still limit logins to specific usernames and require key-based authentication. - Hi,
it seems the system itself supports already using a different port, only Frontview isn't able to handle it.
So what you can do is just creating a backup job and ignoring the fact that you want to use a different SSH port.
As soon as you've created the job login to the NAS by SSH and open the file
/etc/frontview/backup_jobs.conf
in an editor of your choice.
There you will find the configurations of your backup jobs.
To change the SSH port you've got the option to change two settings:
<src_port>
<dst_port>
* If you want to transfer data from a server to your NAS, change the src_port to the desired port.
* If you want to send data from your NAS to a server, change the dst_port.
Here you can see the configuration of a backupJob. I've marked the two parameters which you can adjust.
<backupJob>
<job_id>004</job_id>
<name>backuptoRemote</name>
<enabled>0</enabled>
<sch_every>24</sch_every>
<sch_start>0</sch_start>
<sch_end>23</sch_end>
<sch_dow>127</sch_dow>
<src_type>share</src_type>
<src_share_proto>Files</src_share_proto>
<src_share_vol>data</src_share_vol>
<src_path>Dev</src_path>
<src_login></src_login>
<src_password></src_password>
<src_port>0</src_port>
<src_eject>0</src_eject>
<dst_type>remote</dst_type>
<dst_share_proto>rsync+ssh</dst_share_proto>
<dst_share_vol></dst_share_vol>
<dst_path>my.host.org://home/nasuser/backup</dst_path>
<dst_login>nas</dst_login>
<dst_password></dst_password>
<dst_port>30462</dst_port>
<dst_eject>0</dst_eject>
<opt_full_backup_freq>FIRST_TIME</opt_full_backup_freq>
<opt_remove_previous_backup>0</opt_remove_previous_backup>
<opt_chown_to_share_owner>0</opt_chown_to_share_owner>
<opt_rsync_options>0</opt_rsync_options>
<opt_email_this_to_alert_email>0</opt_email_this_to_alert_email>
<opt_rsync_exclude></opt_rsync_exclude>
<opt_misc_option>0</opt_misc_option>
<wol_addr></wol_addr>
</backupJob>
One important thing:
Whenever you change your backup configuration the configuration file of the backup jobs will be rewritten. Unfortunatly the ports will reset to 0 (default). So you'll have to adjust the ports again after each backup configuration change. :-/
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
