So for the moment, and maybe as a medium to long term solution, I'm uploading a large set of files over rsync. That's saturating the 20Mbs upload so can't ask for more. At the download end I see spikes up to 30Mbs, but how reliable that is only FritzBox could say.

The low speed VPN works well enough for file sharing and access to the central file server. But for big data movements maybe rsync is the way to go. Saves the expense of new VPN routers and configuration.

What could go wrong?

I use rsync reliably on a cron job every fifteen minutes between two sites. Although they're both connected by VPN the rsync uses SSH directly over the internet with appropriate firewall rules in place.

In reply to a post by caffn8me:

I use rsync reliably on a cron job every fifteen minutes between two sites. Although they're both connected by VPN the rsync uses SSH directly over the internet with appropriate firewall rules in place.

Same setup then but I only need rsync once a day. What are "appropriate firewall rules in place"? Just, you know, checking...

In my experience the appropriate firewall rules for SSH are to rate limit connections. You could have a allow list for IP address, but for a bunch of the servers I run that is a none starter. Think login nodes for a HPC cluster and our users are coming from all over the place. And no my servers didn't get hacked unlike a bunch of other HPC sites inthe UK and Europe The collective experience is you can't trust fricking users because they generate private SSH keys that are not protected with a passphrase, and you can't check what the idiots are doing. Consequently SSH key logins have been disabled (never liked them for this very reason). So decent password, three unsuccessful logins IP banned for 5 minutes. Sure the user might write the password down (though this is super unlikely in our scenario as it's their AD password and it's regularly needed). However some state sponsored hacker in China cant see the postit note in your draw unlike your SSH key.

Oh and I would strongly recommend making sure your known_hosts file is hashed. Default on Ubuntu/Debian, not on RHEL derivatives.

On a related note I have setup site to site VPN's between two Edgerouters, and between an Edgerouter and a Draytek. Though I can't get a CentOS 7 box to talk to an Edgerouter. I tend not to use the web interface on the Edgerouters. In fact I can't think when I last logged on, I have a feeling they may be disabled.

Opening up SSH to the outside world is obviously a security risk as some folks have recently discovered.

In my case, appropriate firewall rules means allowing inbound access from specific IP addresses to these servers. All my servers run SSH but not all are accessible from any IP address.

I do run some SSH servers accessible from everywhere (except for countries I've decided are rogue) and for these I run SSH on a non-standard port. I know people will say "but if people scan you they will find your SSH servers anyway" but that's highly unlikely.

Most SSH scans target port 22 and any IP address attempting to connect to me on this port gets autoblocked for a significant period of time. Also, a port scan results in an automatic block for a long time.

If someone does find my SSH server by chance (which has never happened, and I've got the logs to prove it) then they get three attempts at the password before Fail2ban locks them out - again for a significant time. Even if they get the username and password correct, they still need to use multifactor authentication - which is tied to devices in my possession

Thanks for this, all good advice.

In reply to a post by caffn8me:

All my servers run SSH but not all are accessible from any IP address.

I do run some SSH servers accessible from everywhere (except for countries I've decided are rogue) and for these I run SSH on a non-standard port. I know people will say "but if people scan you they will find your SSH servers anyway" but that's highly unlikely.

I have laptop users setup with backup software which runs every hour or so. They move around, their IP changes. So a non-standard SSH port might be a good idea for me. Why is it "highly" unlikely scanners will find that port? Do you recommend any (or a range)? Did I recently read ports for SSH should be below a certain number? 1024 perhaps? I've seen 2222 suggested in the past.

Even if they get the username and password correct, they still need to use multifactor authentication - which is tied to devices in my possession

How can that work for an automated backup script or app? I set the app up to connect to port whatever using name and password. I think that's the limit of what it can do. Long and complex passwords? Or is that another myth? Non-standard usernames maybe?

Thanks again.

In reply to a post by Woolwich:

Did I recently read ports for SSH should be below a certain number? 1024 perhaps?

Ports above 1024 are reserved by the operating system, so you will have to pick something above, that is not already in use. Use the netstat command to see what is in use.

Edited by jchamier (Tue 23-Jun-20 08:52:05)

In reply to a post by jchamier:

Ports above 1024

"below"?

Meanwhile maybe I'm confused and causing confusion.

I specifically want to run an rsync backup and allow an SFTP connection. The app for the SFTP defaults to port 22 so I assumed it needed SSH to be running. But I turned it off and it the SFTP still connects. I'll try and work out if it's the same for rsync. So I can just turn SSH off when I don't need it and when I do it will only be from within my LAN. No more scanners on port 22?

Thinks aloud. SSH = Secure Shell, SFTP = Secure File Transfer Protocol. Two different animals, live in different parts of the woods.

In reply to a post by Woolwich:

How can that work for an automated backup script or app? I set the app up to connect to port whatever using name and password. I think that's the limit of what it can do. Long and complex passwords? Or is that another myth? Non-standard usernames maybe?

Thanks again.

If you need to access remote SSH systems securely you don't use usernames and passwords. Instead you use strong SSH certs and disable password authentication.

In reply to a post by Woolwich:

"below"?

Apologies yes !

SFTP is a relation to SSH, so depending how you've disabled SSH, you may need to check your SSHD config.