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

On 12/03/22 06:06, Dr. Mark Asbach via rsync wrote:
> Hi Dan,
> 
>> Why not rsync directly as root?  Then you can use a passwordless,
passphraseless RSA (or similar) keypair.
I'm not saying I agree with this, but ...
> 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
Not if you use ssh keys - just put each admin's public key in root's 
authorized_keys file.

  ? 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),

Just delete their key.

  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).

Harder, I think. I think with verbose logging, you can see the 
fingerprint of the key that was used, but that seems a bit messy.

  Both are the typical reasons for not using root accounts but going for 
sudo instead ?

I tend to agree with using sudo :-)

OTOH, I have an ansible user that can sudo with no password.

And I do my backups (using dirvish) as root, using a key with a forced 
command.

Maybe that's an option? Each admin has a special key pair for this 
purpose, that allows login as root, but has a forced command on the 
server to do this rsync?

Cheers,
Richard

On 12/03/22 18:38, Richard Hector via rsync wrote:
> And I do my backups (using dirvish) as root, using a key with a forced 
> command.
FWIW, that forced command is here:

https://github.com/rwhector/dirvish-forced-command

It's rather unpolished and undocumented, but comments very welcome :-)

I've also had an issue due to some server-side-only arguments to rsync 
being undocumented, which means I can't validate them, and basically 
have to accept anything ... I'd love to know why this is or has to be 
the case :-) I didn't get any particularly useful answers back in 
January 2019 ...

Cheers,
Richard