Searching through this site has been extremely helpful to me, but I've been stuck on this question for some time. I apologize in advance if it is too trivial.

I have two CentOS 7 servers, A and B. From server A, I need to periodically rsync data through ssh to server B on a disk that is not mounted most of the time, so my A-side cron'ed bash script has to mount that B-side disk first.

I've considered doing things the other way around (having a B-side cron'ed task mounting the disk and rsyncing data from A), but for reasons related to the application, the A to B direction makes much more sense. To make it short, B doesn't know in advance either the (significant number of) folders to rsync or which disk to mount. Only A has this information and knows when the data set is coherent and ready to be rsync'ed.

Of course, ssh-LogAsRoot on server B is not an option, so I was thinking of using an action-limited sudo: I defined a specific user on server B (rsync_user), and gave him the right to sudo-mount without password:

[serverB]# cat /etc/sudoers.d/rsync_user.conf 
rsync_user ALL=NOPASSWD:/usr/bin/mount /dev/md13 /data_mnt

Testing the principle from the command line, I was hoping that this would do the job:

[root@serverA]# ssh -i keyfile rsync_user@serverB 'sudo /usr/bin/mount /dev/md13 /data_mnt'
...Welcome to server B...
[sudo] password for rsync_user:

but server B keeps asking for the sudo password.

I tried to put the sudo mount... command in rsync_user .bashrc instead of passing it through ssh, same result. Is there any restriction in using NOPASSWD-sudo through ssh, or am I missing something in the sudoer config line?

I read about the -t "pseudo tty" switch of ssh, and understood its use for interactive sessions, but I don't see how it can help in a scripted connection.

At this stage, I'm considering setting up some sort of text-file-based command/response exchange between A and B, like having the rsync_user raising a flag in a text file on server B through ssh, and a short-period monitoring root-task of server B would detect this flag to mount the required disk, and would signal to server A when done... but I'm sure there's an easier, built-in and secure way to do this.

So, am I on the right path with the "sudo mount" approach or would you recommend another method?

  • On server B, as the rsync_user, can you sudo /usr/bin/mount /dev/md13 /data_mnt?
    – roaima
    Mar 27, 2021 at 9:19
  • @roaima Yes, I can, without password.
    – fargo2021
    Mar 27, 2021 at 10:30
  • Have you tried ssh -t ... or even ssh -tt ...?
    – roaima
    Mar 27, 2021 at 17:00

1 Answer 1


I would go with command option which would be put into remote .ssh/authorized_keys and would call a wrapper which based on a path requested to rsync would mount the disk via sudo (or better would call another wrapper for sudo as sudo wildcards are pretty scary), then based on SSH_ORIGINAL_COMMAND would do the rest.

command="sh $HOME/bin/rsync_wrapper" ssh-rsa ... rsync-job

You should investigate how rsync is called on remote host. You can get an idea how this Samba rsync wrapper works https://www.samba.org/ftp/unpacked/rsync/support/rrsync (ie. rsync client calls on remote node something like rsync --server --sender -vlogDtpr --partial . <ARGS> which is accessible via SSH_ORIGINAL_COMMAND).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .