LWN: Comments on "OpenSSH 8.0 released "

OpenSSH 8.0 released

mbunkus — Tue, 30 Apr 2019 15:14:44 +0000

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.

OpenSSH 8.0 released

nix — Tue, 30 Apr 2019 15:07:04 +0000

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

mbunkus — Tue, 30 Apr 2019 14:59:19 +0000

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

excors — Tue, 30 Apr 2019 14:46:59 +0000

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

ScottMinster — Tue, 30 Apr 2019 12:45:02 +0000

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

mbunkus — Tue, 30 Apr 2019 07:01:41 +0000

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

ScottMinster — Mon, 29 Apr 2019 22:04:20 +0000

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

muwlgr — Sun, 28 Apr 2019 20:34:30 +0000

You are supposed to have the most of control you wish by using authorized_keys under ~/.ssh/

OpenSSH 8.0 released

naptastic — Sat, 27 Apr 2019 22:49:42 +0000

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

rsync mnemonic

karkhaz — Fri, 26 Apr 2019 23:49:02 +0000

That's a beautiful analogy :-)

rsync mnemonic

naptastic — Fri, 26 Apr 2019 21:43:22 +0000

The choice seemed arbitrary to me until I came up with a mnemonic for it: Trailing slash means "the contents of the directory," and no trailing slash means "the directory as a single thing." Somehow my brain also maps that to pointers versus values:

rsync(src, dest);  /* one item, named 'src', will be created in dest */
rsync(*src, dest); /* everything under 'src' will be created in dest */

I don't know if that helps or even makes sense to anyone else.

OpenSSH 8.0 released

gevaerts — Wed, 24 Apr 2019 11:39:00 +0000

I would never do that. My fingers know cpio much better for that usecase :)

OpenSSH 8.0 released

nilsmeyer — Wed, 24 Apr 2019 10:44:09 +0000

Very often I find myself piping tar through SSH, especially when I need to use sudo.

OpenSSH 8.0 released

Pc5Y9sbv — Mon, 22 Apr 2019 22:09:53 +0000

Along the same lines, I eventually started using the -R (--relative) flag to rsync in my most confident idempotent transfer mode:

rsync -avRP host:/prefix1/./rel1 host:/prefix2/./rel2 /prefix3/.

This creates /prefix3/rel1 and /prefix3/rel2 hierarchies with the easy to understand semantics that it splices the trees at the '.' point. Also, for me the --excludes/--includes patterns are easier to understand when I know they will be rooted at the '.' as well.

OpenSSH 8.0 released

oldtomas — Mon, 22 Apr 2019 09:12:41 +0000

Quoth the man page:

"A trailing slash on the source changes this behavior to avoid creating an additional directory level at the destination. You can think of a trailing / on a source as meaning 'copy the contents of this directory' as opposed to 'copy the directory by name', but in both cases the attributes of the containing directory are transferred to the containing directory on the destination"

(And for the reverse: just searching for "trailing" or "trailing slash" clears that part up pretty quickly).

Rsync's man page may be daunting, but it is extremely well written.

"If all else fails, read the instructions"

This

Darkmere — Sun, 21 Apr 2019 09:15:28 +0000

I thought it mounted them in /run/$USER/ these days for all mounts?

And, I rather like that behavior of Gnome these days, it means I can do basic exploration in the GUI, and if I want to muck around with my command line tools or services that don't speak that layer, I can just access them as normal filesystems.

Very convenient.

This

lkundrak — Sun, 21 Apr 2019 05:17:08 +0000

> although it mounts to POSIX/FUSE with a space in the mount location under ~/.gvfs which is really stupid....)

Why is it stupid?

This

scientes — Sun, 21 Apr 2019 00:49:01 +0000

This is exactly the behavior scp should have. I actually long though they were the same protocol, because I had such good experience using sftp mounted via gvfs in nautilus (although it mounts to POSIX/FUSE with a space in the mount location under ~/.gvfs which is really stupid....)

OpenSSH 8.0 released

karkhaz — Sat, 20 Apr 2019 22:11:23 +0000

So first of all, I don't think a slash on the destination ever matters.

A slash on the source directory does change rsync's behaviour, but that has nothing to do with whether the destination exists. The behaviours are orthogonal, here is a matrix:

when dst doesn't exist
rsync -a src/ dst --> creates dst, copies contents of src into dst
rsync -a src dst --> creates dst, copies src into dst

when dst exists
rsync -a src/ dst --> copies contents of src into dst
rsync -a src dst --> copies src into dst

I do remember being surprised by this when I first used rsync, but the man page is fairly clear about it; I'm curious to hear if what behaviour you might find less surprising, while retaining the ability to copy either a directory or its contents (without using shell wildcards or the like)?

OpenSSH 8.0 released

marcH — Sat, 20 Apr 2019 17:47:27 +0000

> I'm not sure that's true

Why didn't you just try it? It's not like this requires a complex setup.

Yes, a trailing slash "src/" in the rsync source means "src/*". It's not the most intuitive syntax but it's a useful feature.

That wasn't the point though, the point was: run the same "cp -r" command twice and it can give different results the second time on Linux. Run the same command on macOS and it can behave differently again. None of that craziness with rsync.

OpenSSH 8.0 released

dw — Sat, 20 Apr 2019 11:06:37 +0000

I'm not sure that's true. Some combination of 'with slash' or 'without slash' on either the source or dest changes behaviour if the target already exists as a directory. I never stop to figure out what went wrong, so can't be more specific than "something to do with slashes". I hate this aspect of rsync's UI

OpenSSH 8.0 released

marcH — Sat, 20 Apr 2019 07:16:48 +0000

Just remembered one of the reasons I stopped using "cp -r". Assuming dst/ doesn't exist yet, then running this twice:

cp -r src/ dst/
cp -r src/ dst/

... does something different the second time on Linux (not on macOS).

Running the same rsync command twice never does something different the second time, that's crazy.

OpenSSH 8.0 released

marcH — Sat, 20 Apr 2019 07:05:13 +0000

You can transfer your muscle memory "as is" to rsync which has the same basic syntax; then start enjoying the additional features.

I don't remember the last time I used "cp" to perform a recursive copy... locally.

OpenSSH 8.0 released

bmur — Sat, 20 Apr 2019 01:53:31 +0000

Like k8to above, moving files with scp is built into my muscle memory.

As long as "scp file.tgz user@host:" continues to work, I really don't care one bit if it's handled by the scp, sftp, or some other secure protocol under the covers.

For version 9, keep the same exact scp command line syntax and make the underlying protocol sftp by default. Add a command line option to explicitly request the scp protocol for anyone who really must have it. I would bet most people don't care how the bits travel the wire.

OpenSSH 8.0 released

epa — Fri, 19 Apr 2019 01:33:09 +0000

It seems like the obvious step if the old scp protocol is to be killed off. Nobody uses scp because they particularly love the protocol -- it's just for convenience, a familiar command line syntax, or because there are old shell scripts that call it.

OpenSSH 8.0 released

epa — Fri, 19 Apr 2019 01:12:33 +0000

When you get back a filename from the server you check that it is a relative path (does not begin /) and is canonical (does not contain ..). And you check that it is a possible expansion of the glob pattern you gave (which is effectively the same as doing a regular expression match, just with different syntax). That should be enough.

OpenSSH 8.0 released

perennialmind — Fri, 19 Apr 2019 00:01:18 +0000

Putty's PSCP does what you describe: it has a -sftp and a -scp, defaulting to the former and falling back to the latter. I might have switched to it by now if it consulted ~/.ssh. I rather like the idea of a one-shot command with support for those and a -rsync as well. scp's behavior is trivial to internalize, but what I've internalized for rsync is that it's subtle and that I need to consult the man page every time.

OpenSSH 8.0 released

k8to — Thu, 18 Apr 2019 22:57:27 +0000

That vulnerability is a bit odd.
In scp, I can do

scp server:/path/to/a/file.txt target.txt

and this should open and write to target.txt. I would be surprised if the server knew about that at all. Though I don't know.

Since that's implemented somehow, you would expect

scp server:/path/to/a/file.txt .

to just be client shorthand for

scp server:/path/to/a/file.txt ./file.txt

It seems seriously weird that it would not.

But there is also functionality like this:

scp server:/path/to/* .

where you just trust the remote server won't send you evil filenames that will destroy your world. And I don't see how you can solve that problem.

So it seems that the specific-file codepaths lazily used the known-file filepaths. Which is unfortunate, but not shocking, since scp -r is commonly enough used.

OpenSSH 8.0 released

k8to — Thu, 18 Apr 2019 22:51:56 +0000

Rhetorical? I don't think scp has these capabilities.

OpenSSH 8.0 released

epa — Thu, 18 Apr 2019 22:26:17 +0000

So can scp(1) use the rsync or ftp protocols instead, but with the same command line syntax as before?