OpenSSH 8.0 released [LWN.net]

OpenSSH 8.0 released

Posted Apr 20, 2019 1:53 UTC (Sat) by bmur (guest, #52954)
Parent article: OpenSSH 8.0 released

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.

to post comments

OpenSSH 8.0 released

Posted Apr 20, 2019 7:05 UTC (Sat) by marcH (subscriber, #57642) [Link] (8 responses)

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

Posted Apr 20, 2019 7:16 UTC (Sat) by marcH (subscriber, #57642) [Link] (7 responses)

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

Posted Apr 20, 2019 11:06 UTC (Sat) by dw (subscriber, #12017) [Link] (5 responses)

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

Posted Apr 20, 2019 17:47 UTC (Sat) by marcH (subscriber, #57642) [Link]

> 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

Posted Apr 20, 2019 22:11 UTC (Sat) by karkhaz (subscriber, #99844) [Link] (3 responses)

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

Posted Apr 22, 2019 9:12 UTC (Mon) by oldtomas (guest, #72579) [Link]

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"

rsync mnemonic

Posted Apr 26, 2019 21:43 UTC (Fri) by naptastic (guest, #60139) [Link] (1 responses)

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.

rsync mnemonic

Posted Apr 26, 2019 23:49 UTC (Fri) by karkhaz (subscriber, #99844) [Link]

That's a beautiful analogy :-)

OpenSSH 8.0 released

Posted Apr 22, 2019 22:09 UTC (Mon) by Pc5Y9sbv (guest, #41328) [Link]

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

Posted Apr 24, 2019 10:44 UTC (Wed) by nilsmeyer (guest, #122604) [Link] (10 responses)

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

OpenSSH 8.0 released

Posted Apr 24, 2019 11:39 UTC (Wed) by gevaerts (subscriber, #21521) [Link]

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

OpenSSH 8.0 released

Posted Apr 27, 2019 22:49 UTC (Sat) by naptastic (guest, #60139) [Link] (8 responses)

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 28, 2019 20:34 UTC (Sun) by muwlgr (guest, #35359) [Link]

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

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.