OpenSSH 8.0 released [LWN.net]

OpenSSH 8.0 released

Posted Apr 27, 2019 22:49 UTC (Sat) by naptastic (guest, #60139)
In reply to: OpenSSH 8.0 released by nilsmeyer
Parent article: OpenSSH 8.0 released

I've wondered for a long time how people do things like rsync to root-owned destinations when their systems don't allow direct root SSH. I'm almost scared to ask, but can you elaborate on how it's done?

The top result via Google is from Ask Ubuntu [1], and--don't do this--it recommends adding "ALL=NOPASSWD:<path to rsync>" to sudoers, which is terrifying on so many levels.

(In case it's unclear, really, DO NOT EVER DO THIS. Running rsync as root means arbitrary file operations as root. It will let any program on your system to get root for free: just drop in a malicious shared library, steal the nearest Bitcoin wallet, and eat all the cheese in the house.)

[1] https://askubuntu.com/questions/719439/using-rsync-with-sudo-on-the-destination-machine

OpenSSH 8.0 released

Posted Apr 29, 2019 22:04 UTC (Mon) by ScottMinster (subscriber, #67541) [Link] (6 responses)

I don't think the sudoers suggestion is as bad as you make it out to be, at least in the particular case where the user in question is presumed to be the system admin. The post recommends adding that line to sudoers for a specific user, and a specific rsync path, as in "naptastic ALL=NOPASSWD:/usr/bin/rsync". Then that user account could "sudo rsync" to run the rsync command as root without a password.

You're right, of course, that when running rsync as root can be disastrous if misused. And leaving that configuration does allow someone who has gotten access to that admin's user account to much more easily get root access, which would be very bad. As a temporary solution to preserve multiple UIDs/GIDs in a transfer, it's not awful. Eventually, those writes have to be done as root. I would probably prefer to do the operation the other direction -- run rsync as root on the destination machine. That way, no permanent sudoers changes would be required, which one might forget to remove.

OpenSSH 8.0 released

Posted Apr 30, 2019 7:01 UTC (Tue) by mbunkus (subscriber, #87248) [Link] (5 responses)

As soon as you grant a user sudo without a password to any program that can write to arbitrary files (rsync, tar, cp, sed, awk, tee, bash, Perl, Python, whatever), that account becomes root for all intents and purposes. It's trivial to gain real root in such a scenario, simply by using your "write to any file" program to create a new sudoers file with passwordless access to everything (among many, many other scenarios).

If you're disallowing root login via ssh, you're doing it for security purposes, and by allowing passwordless sudo to such commands you completely counteract those security purposes. You'd have to handle the security for that account the same way you're handling it for root: disallow login via ssh completely. Or to frame it differently: if you enable passwordless sudo rsync, you could just as well re-enable root login via ssh (with public keys, please!) as it would be less hassle and no less secure.

For my own machines I generally disable ssh root login for unknown addresses and often allow it for known-good addresses using "Match" blocks in sshd_config, e.g.

PermitRootLogin no

Match Address 2001:db8::/64
PermitRootLogin prohibit-password

OpenSSH 8.0 released

Posted Apr 30, 2019 12:45 UTC (Tue) by ScottMinster (subscriber, #67541) [Link] (2 responses)

I completely agree with what you wrote, which is why I suggested that the sudoers modification (if used at all) be temporary.

But is there a better way to solve the original problem? If you have a directory tree with files with varying user and group IDs that you want to sync to a remote server, what is the best way to do it?

Using tar (something like "tar -c . | ssh server2 sudo tar -C /path/to/dest -x") would work if you didn't care about transferring all the data. If the destination is empty, you'd have to do that anyway. But suppose you just needed to update the copy?

I would expect that running 'rsync' as root on the destination machine would work, as in "rsync -a server1:/path/to/source /path/to/dest". But that assume that you can ssh from server2 to server1, which isn't always the case.

Is there some more obvious method I'm missing?

OpenSSH 8.0 released

Posted Apr 30, 2019 14:46 UTC (Tue) by excors (subscriber, #95769) [Link]

I think you can just provide the password to the remote sudo, like:

rsync -e 'ssh -X' --rsync-path='SUDO_ASKPASS=/usr/bin/ssh-askpass /usr/bin/sudo -A /usr/bin/rsync' -a server1:/path server2:/path

OpenSSH 8.0 released

Posted Apr 30, 2019 14:59 UTC (Tue) by mbunkus (subscriber, #87248) [Link]

You could try what excors wrote about using sudo-rsync with a password.

Another thing you can try if your source machine allows root-login-via-ssh is reversing the direction of the transfer: instead of running rsync on "source" ssh'ing to "destination", ssh from "source" to "destination" with a reverse port forwarding to "source:22" and run rsync on "destination" with "localhost:<forwardedPort>" as the source address.

OpenSSH 8.0 released

Posted Apr 30, 2019 15:07 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

As soon as you grant a user sudo without a password to any program that can write to arbitrary files (rsync, tar, cp, sed, awk, tee, bash, Perl, Python, whatever), that account becomes root for all intents and purposes.

Not for all: the user is still protected from typos and accidents -- just not from malicious attackers executing code as the user.

OpenSSH 8.0 released

Posted Apr 30, 2019 15:14 UTC (Tue) by mbunkus (subscriber, #87248) [Link]

Sure, my statement was a bit too general. The original question was how to rsync root-owned stuff while root login via ssh is prohibited, and you do that in order to increase security, not in order to in order to make typos less dangerous. My comment was therefore meant that the two accounts are almost equivalent wrt. to security, especially regarding access from untrusted sources.