0

I'm using rsync to repeatedly send a folder from source to destination. When using a straight bash command, it prompts for a password. In order to prevent the prompting of a password, I've made a simple cpp program that calls a bash script of rsync to repeatedly send the folder to the destination by doing fork and exec. I tried this answer, but it returns an error:

sudo rsync $args --password-file=rsync_pass -avz /home/user/folder/checkpoints/$1 secondaryvm@192.xxx.xxx.xxx::checkpoints/$1

rsync: failed to connect to 192.xxx.xxx.xxx (192.xxx.xxx.xxx): Connection refused (111)
rsync error: error in socket IO (code 10) at clientserver.c(127) [sender=3.1.3]

Note: I only want to use the --password-file option

I have checked that the rsync daemon is running on the destination side by running the command: sudo systemctl status rsync. Here's my rsyncd.conf

pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
log file = /var/log/rsync.log
port = 12000

[files]
path = /home/public_rsync
comment = RSYNC FILES
read only = true
timeout = 300

How do I get this working?

Chris Davies
  • 116,213
  • 16
  • 160
  • 287
y_159
  • 137
  • 1
  • 9
  • You could use public key authentication if you don't want to enter a password, no need for a daemon. [Edit] your question and add your /etc/rsyncd.conf. Are auth users and secrets file defined and properly setup? – Freddy Oct 30 '20 at 08:02
  • The connection is being refused. This means either that the service is not running (on the standard port), or that there is a firewall somewhere on or between client and server rejecting such connections. – Chris Davies Oct 30 '20 at 08:22
  • @Freddy where are these auth users and secrets file present? – y_159 Oct 30 '20 at 09:31
  • @roaima how can i check that? – y_159 Oct 30 '20 at 09:31
  • @roaima sudo systemctl status rsync on backup side – y_159 Oct 30 '20 at 10:28
  • @Freddy have a look at the updated question. – y_159 Oct 30 '20 at 11:52
  • Your command references the module checkpoints but your configuration defines files – Chris Davies Oct 30 '20 at 21:13
  • @roaima what difference will that make – y_159 Oct 31 '20 at 04:09
  • If you try to reference a module that's not been defined you won't be able to access any files. (Not a reason for "connection refused", but relevant nevertheless.) – Chris Davies Nov 01 '20 at 20:27

1 Answers1

1

The connection was refused because you were using a non-standard rsync port, see the comments by user roaima.

For simplicity, I expect user public_rsync with home directory /home/public_rsync exists on the destination host (192.xxx.xxx.xxx, where the daemon is running) and the service is not blocked by your firewall.

Start with this sample /etc/rsyncd.conf (passwords are enabled later):

pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
log file = /var/log/rsync.log

[checkpoints]
path = /home/public_rsync/checkpoints
comment = RSYNC FILES
read only = false
uid = public_rsync
gid = public_rsync
#auth users = secondaryvm
#secrets file = /etc/rsyncd.secrets
timeout = 300

Explanation:

  • remove port = 12000 to use default port 873
  • change module name from [files] to [checkpoints]
  • change the path to the module directory to /home/public_rsync/checkpoints
  • change read only = true to false to be able to push files to the server
  • add uid / gid to use this username / group when transferring files

Then restart the server:

sudo systemctl restart rsync

1. Test rsync on the destination host as user public_rsync

  1. List all listable modules with rsync localhost::, it should return the module name and the description:

    public_rsync@192.xxx.xxx.xxx:~$ rsync localhost::
checkpoints      RSYNC FILES

  2. Create directory checkpoints and a test file in this directory:

    public_rsync@192.xxx.xxx.xxx:~$ mkdir ~/checkpoints
public_rsync@192.xxx.xxx.xxx:~$ echo helloworld > ~/checkpoints/helloworld.txt

  3. List all files of our module:

    public_rsync@192.xxx.xxx.xxx:~$ rsync localhost::checkpoints
drwxrwxr-x          4,096 2020/10/30 18:26:01 .
-rw-rw-r--             11 2020/10/30 18:26:01 helloworld.txt

2. Test rsync from the source host, make sure pull/push are working

  1. Test pull:

    $ rsync 192.xxx.xxx.xxx::checkpoints/helloworld.txt /tmp/
$ cat /tmp/helloworld.txt
helloworld

  2. Test push:

    $ rsync /tmp/helloworld.txt 192.xxx.xxx.xxx::checkpoints/helloworld_push.txt

  3. List files of module checkpoints again:

    $ rsync 192.xxx.xxx.xxx::checkpoints
drwxrwxr-x          4,096 2020/10/30 18:29:06 .
-rw-rw-r--             11 2020/10/30 18:26:01 helloworld.txt
-rw-r--r--             11 2020/10/30 18:29:06 helloworld_push.txt

3. Enable authentication

Now that we know rsync works as expected, enable authentication on the destination host:

  1. Create text file /etc/rsyncd.secrets with username and password for user secondaryvm (the username is arbitrary, no user account needed):

    user@192.xxx.xxx.xxx:~$ sudo tee /etc/rsyncd.secrets > /dev/null <<'EOF'
secondaryvm:12345
EOF
user@192.xxx.xxx.xxx:~$ sudo chmod 600 /etc/rsyncd.secrets

  2. Uncomment auth users and secrets file in /etc/rsyncd.conf, restart the server:

    user@192.xxx.xxx.xxx:~$ sudo systemctl restart rsync

4. Test authentication (from source host)

Connecting without credentials should not be possibly any more, you're supposed to enter a password:

$ rsync 192.xxx.xxx.xxx::checkpoints
Password:
@ERROR: auth failed on module checkpoints
rsync error: error starting client-server protocol (code 5) at main.c(1675) [Receiver=3.1.3]

Provide username and password for the connection, e.g.

$ echo '12345' > rsync_pass
$ chmod 600 rsync_pass
$ rsync --password-file=rsync_pass secondaryvm@192.xxx.xxx.xxx::checkpoints

If anything doesn't work, add verbosity with option -v and check the daemon log /var/log/rsync.log.

Freddy
  • 25,565
  • sorry i didn't checked this for some days. I followed the public key authentication answers on some pages. But what is happening now is it is unable to send some files which are permission protected. and throws this error: rsync: send_files failed to open "/home/usr/...../checkpoints/246/descriptors.json": Permission denied (13) – y_159 Nov 04 '20 at 12:28
  • public/private key process doesn't require passwords for transmission. but for these files it requires sudo and requires user to input password of destination – y_159 Nov 04 '20 at 12:30
  • Make sure that the files are readable by the rsync user (you could use a group for that), directories should also have the executable bit set. – Freddy Nov 04 '20 at 13:15
  • do you mean to say something like creating a group of users on the directory? What my scenario is there's repeatedly some folders are added into a directory, and i've to repeatedly send those folders to backup. – y_159 Nov 04 '20 at 13:37
  • That was the idea, but if the files in that directory belong to different users/groups that doesn't make sense. You could create an entry in your /etc/sudoers file to call your script with passwordless sudo, see unix.stackexchange.com/a/229653/332764 for an example and replace username/path to the script. Or create a script with passwordless sudo to change ownership/permissions on the files before you call your sync script as normal user. Use public key authentication or the version with password file from my answer. – Freddy Nov 04 '20 at 23:14
  • Hi, this solution is not working. – y_159 Nov 05 '20 at 05:04
  • Please ask a new question. It's difficult to help in the comments section and the permissions problem is not related to the original question. You can add a link to refer to this question. Thank you. – Freddy Nov 05 '20 at 13:18
  • sorry I know comments could not give you better clarity. head over to here pls. https://stackoverflow.com/questions/64691809/sudoless-passwordless-script – y_159 Nov 05 '20 at 13:48