You are here

ssh: Connection refused rsync: connection unexpectedly closed

Submitted by Druss on Mon, 2014-09-01 22:30

I ran into the following error while running a script that was performing backups of files via rsync over ssh.

error: ssh: connect to host foo.example.com port 22: Connection refused rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]

As you can see, the message points to an SSH error. Testing the statement outside the script resulted in no errors. Furthermore, similar SSH calls were executed fine earlier in the same script. At a certain point, the SSH call failed and all subsequent calls failed in an identical manner. This was certainly suspicious and it took me some time to figure out what was going wrong.

The answer is that this was a firewall error. In particular, this was a UFW error. UFW stands for "Uncomplicated FireWall" and is a user-friendly wrapper for the more complex iptables. The destination server was using UFW rather than iptables for its firewall security and as a (default) precaution, UFW sets a "rate limit" on SSH connections. IOW, if you make an SSH connection attempt more than X times in 30 seconds, it will shut you out for a while.

As for a solution, I did look (not too hard though) for a UFW solution. However, there does not appear to be any UFW solution to this issue. It does not allow you to simply disable rate limiting. While the program does provide configuration files in /etc/ufw, the only way to turn off rate limiting is apparently to edit and mutilate the rate limiting rules declared in /lib/ufw/user.rules. Since stuff like this is what will come and bite you in the ass six months down the line when UFW gets an update, I decided against hacking the lib file.

I had two options now:

  1. Ditch UFW altogether and replace it with iptables that I could control and adjust as needed.
  2. Give my script (and the user it was logging in as) access to UFW. Once the script logged in, it could disable UFW, perform its tasks, and then re-enable UFW. There will, of course, be a brief window when the server will be shivering naked on the Internet.

I chose to go with the first option and all is well now :)

Hope this helps someone out there!

P.S. If you know of a clean way to sort this issue out in UFW, please leave a note :)
P.P.S. The servers in question are Debian 6 (local) and Ubuntu 14.04 (remote).