There's three potential hurdles.
(a) ensure the source "src" box can 'ssh' into the destination "dst" box without a password.
(b) unix file permissions.
(c) keeping it simple but with a mind to security.
Take user "foo" on "src" wants to copy root files to "dst"..
foo@src $ sudo id
^^^if that works then fine. Your first post indicated it does.
You essentially want..
foo@src $ sudo rsync --progress -auxv /wrk/ root@dst:/wrk/
^^^to keep dst:/wrk up to date with src:/wrk
Ignore my rsync options except to say I chose them because they are non-destructive to src:/wrk ("-c" for ((intensive)) checksum but man rsync).
^^^enable ssh root login on "dst" (/etc/ssh/sshd_config -> PermitRootLogin yes, restart sshd on dst. Possibly generate ssh key on root@dst (if not present already) then copy root@src:~/.ssh/id_rsa.pub (or whatever key) to dst and append to root@dst:~/.ssh/authorized_keys. Test..
root@src $ ssh root@dst
^^^should work without password.
That solves it for (a). Bear in mind it is a bad idea to allow passwordless root sshd login generally and the risk ramps up if either foo@src or root@dst is an internet facing machine. Having said that I do it myself inside my own network for the three hypervisors I run.
For (b) & (c) you might use a non root account for dst. It's a viable option when dst only needs to store an archive rather than access the files. You'd still be root on src but fling src:/wrk/ to dst:/wrk over ssh using (typically) tar such that bar@dst:/wrk ends up with a tarball, bar@dst:/wrk/src-wrk.tar.gz. Only requires passwordless login for bar@dst rather than root@dst.
There is also 'sshpass' which does what you ask (man sshpass). Very much frowned upon because it almost always gets abused by folk who don't care to think out (c) but under the right circumstances can be more secure (eg: adhoc jobs).
foo@src $ sshpass -p 'root@dst password' ssh root@dst
^^^noting that if 'ssh' asks any questions nothing will appear to happen (do 'ssh root@dst' manually - typically "Are you sure you want to continue connecting") and that with changing ip addresses the issue can randomly occur. You'll need extra options to 'ssh' to suppress that and I can't recall them. Last time I used 'sshpass' was to help a co-worker globally change a flag on a bunch of cisco devices .. many years ago. You'll note from the sshpass manpage even the author does not like his own tool. Perhaps he had to faff about with a load of cisco devices!
(a) is best compromise.
As you mention www-data the real solution is to match the uid/gid on the two boxes when the infrastructure was first designed. If both 'httpd' match then you can rsync directly using (say) apache@src -> apache@dst or even NFS (v4 - older is firewall nightmare).