rsync - Mar 2022 - Trying to elevate rsync privileges when connecting over ssh without using NOPASSWD in sudoers

Why not rsync directly as root?  Then you can use a passwordless,
passphraseless RSA (or similar) keypair.

On Fri, Mar 11, 2022 at 4:58 AM Dr. Mark Asbach via rsync <
rsync at lists.samba.org> wrote:
> Hi there,
>
> We are using ansible to deploy system configuration and web application
> source code to clusters of Linux computers. One part of this process
> requires transferring large directories to the target hosts, which is done
> using the ?synchronize? command in ansible that is in turn a wrapper around
> rsync. This work great in most scenarios, but we run into an issue with a
> specific (albeit for us: prominent) use case:
>
> - We try to have rsync connect over ssh using a non-privileged user
> account.
> - The account is set up for publickey authentication, so we can use ?rsync
> -e ?ssh -i /home/user/.ssh/some_id??.
> - On the target side, we want to escalate privileges for rsync, which we
> try using ?rsync --rsync-path=?sudo rsync??.
>
> This whole scenario works fine, as long as for the ssh account we use for
> logging in, passwordless sudo is set up on the target. For security
> reasons, we do not want to go this route. Instead, we want to supply the
> user?s password for gaining privileges. On the web, I?ve found to
> suggestions for solving this:
>
> a) Using ssh-askpass, we can use the options -e "ssh -X"
> --rsync-path="sudo -A rsync" (see
https://askubuntu.com/a/1167758). The
> problem in our scenario is that using ansible, we run the identical rsync
> command on multiple hosts in parallel (we target about 32 VMs in one go).
> So the person running the script would have to enter the password into 32
> dialogs exactly at the time they pop up.
>
> b) Passing the password to sudo via stdin using --rsync-path "echo
> MYPASSWORD | sudo -S rsync" (see https://askubuntu.com/a/1155897).
This
> has the potential security implication that if the calling line is stored
> somewhere in a shell history file of the control host, the password will be
> breached, but there?s a couple of measures we can take so mitigate that.
> However, I fail at getting this to run.
>
> Here?s a sample command that I get out of a patched ansible ?synchronize?
> command. I?m trying to connect to a Ubuntu 18.04 VM with the user account
> ?mark? that is in the ?sudoers? group but does not have ?NOPASSWD? set, so
> running ?sudo? for the first time in a session will require to enter the
> password for ?mark? which here is ?test?:
>
> rsync --delay-updates -F --compress --delete-after --archive --no-perms
> --no-owner --no-group --rsh='/usr/bin/ssh -S none -i
~/ssh/some_private_key
> -o Port=2222 -o StrictHostKeyChecking=no -o
UserKnownHostsFile=/dev/null'
> --rsync-path='echo test | sudo -S -u root rsync 2>/dev/null'
> --out-format='<<CHANGED>>%i %n%L' ~/test_source_dir
mark at 127.0.0.1:
> /some/test_target_dir
>
> This is what I get:
> > Warning: Permanently added '[127.0.0.1]:2222' (ED25519) to the
list of
> known hosts.
> > rsync: connection unexpectedly closed (0 bytes received so far)
[sender]
>
> As far as I understand, this could be due to "sudo -S" prompting
for the
> password and that prompt interfering with the rsync communications.
> However, I?m out of ideas what I could do to get around that.
>
> Help would be greatly appreciated ;-)
>
> Thanks and greetings from Cologne,
> Mark--
> Please use reply-all for most replies to avoid omitting the mailing list.
> To unsubscribe or change options:
> https://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20220311/787b19fc/attachment.htm>

Hi Dan,
> Why not rsync directly as root?  Then you can use a passwordless,
passphraseless RSA (or similar) keypair.
That?s because these are cloud instances that get maintained by multiple admins.
If we require all of them to log in as root, we would have to share the root
password ? and that would on one hand be a security/maintainability issue (if
one person leaves the team, we?ll have to change and redistribute the root
password), on the other hand it would violate accountability (log files would
only show logins by ?root? and after an issue, there would be no chance to know
whom to ask about strange things). Both are the typical reasons for not using
root accounts but going for sudo instead ?

Thanks anyway. Every idea helps!

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4652 bytes
Desc: not available
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20220311/e2036184/smime.bin>