OpenSSH 8.0 released [LWN.net]

OpenSSH 8.0 released

Posted Apr 30, 2019 7:01 UTC (Tue) by mbunkus (subscriber, #87248)
In reply to: OpenSSH 8.0 released by ScottMinster
Parent article: OpenSSH 8.0 released

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

to post comments

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.