OpenSSH 8.0 released
This release contains mitigation for a weakness in the scp(1) tool and protocol (CVE-2019-6111): when copying files from a remote system to a local directory, scp(1) did not verify that the filenames that the server sent matched those requested by the client. This could allow a hostile server to create or clobber unexpected local files with attacker-controlled content. This release adds client-side checking that the filenames sent from the server match the command-line request, The scp protocol is outdated, inflexible and not readily fixed. We recommend the use of more modern protocols like sftp and rsync for file transfer instead."
From: | Damien Miller <djm-AT-openbsd.org> | |
To: | lwn-AT-lwn.net | |
Subject: | Announce: OpenSSH 8.0 released | |
Date: | Wed, 17 Apr 2019 18:32:01 -0600 (MDT) | |
Message-ID: | <ab3251975c795ebf@openbsd.org> | |
Archive-link: | Article |
OpenSSH 8.0 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: http://www.openssh.com/donations.html Security ======== This release contains mitigation for a weakness in the scp(1) tool and protocol (CVE-2019-6111): when copying files from a remote system to a local directory, scp(1) did not verify that the filenames that the server sent matched those requested by the client. This could allow a hostile server to create or clobber unexpected local files with attacker-controlled content. This release adds client-side checking that the filenames sent from the server match the command-line request, The scp protocol is outdated, inflexible and not readily fixed. We recommend the use of more modern protocols like sftp and rsync for file transfer instead. Potentially-incompatible changes ================================ This release includes a number of changes that may affect existing configurations: * scp(1): Relating to the above changes to scp(1); the scp protocol relies on the remote shell for wildcard expansion, so there is no infallible way for the client's wildcard matching to perfectly reflect the server's. If there is a difference between client and server wildcard expansion, the client may refuse files from the server. For this reason, we have provided a new "-T" flag to scp that disables these client-side checks at the risk of reintroducing the attack described above. * sshd(8): Remove support for obsolete "host/port" syntax. Slash- separated host/port was added in 2001 as an alternative to host:port syntax for the benefit of IPv6 users. These days there are establised standards for this like [::1]:22 and the slash syntax is easily mistaken for CIDR notation, which OpenSSH supports for some things. Remove the slash notation from ListenAddress and PermitOpen; bz#2335 Changes since OpenSSH 7.9 ========================= This release is focused on new features and internal refactoring. New Features ------------ * ssh(1), ssh-agent(1), ssh-add(1): Add support for ECDSA keys in PKCS#11 tokens. * ssh(1), sshd(8): Add experimental quantum-computing resistant key exchange method, based on a combination of Streamlined NTRU Prime 4591^761 and X25519. * ssh-keygen(1): Increase the default RSA key size to 3072 bits, following NIST Special Publication 800-57's guidance for a 128-bit equivalent symmetric security level. * ssh(1): Allow "PKCS11Provider=none" to override later instances of the PKCS11Provider directive in ssh_config; bz#2974 * sshd(8): Add a log message for situations where a connection is dropped for attempting to run a command but a sshd_config ForceCommand=internal-sftp restriction is in effect; bz#2960 * ssh(1): When prompting whether to record a new host key, accept the key fingerprint as a synonym for "yes". This allows the user to paste a fingerprint obtained out of band at the prompt and have the client do the comparison for you. * ssh-keygen(1): When signing multiple certificates on a single command-line invocation, allow automatically incrementing the certificate serial number. * scp(1), sftp(1): Accept -J option as an alias to ProxyJump on the scp and sftp command-lines. * ssh-agent(1), ssh-pkcs11-helper(8), ssh-add(1): Accept "-v" command-line flags to increase the verbosity of output; pass verbose flags though to subprocesses, such as ssh-pkcs11-helper started from ssh-agent. * ssh-add(1): Add a "-T" option to allowing testing whether keys in an agent are usable by performing a signature and a verification. * sftp-server(8): Add a "lsetstat@openssh.com" protocol extension that replicates the functionality of the existing SSH2_FXP_SETSTAT operation but does not follow symlinks. bz#2067 * sftp(1): Add "-h" flag to chown/chgrp/chmod commands to request they do not follow symlinks. * sshd(8): Expose $SSH_CONNECTION in the PAM environment. This makes the connection 4-tuple available to PAM modules that wish to use it in decision-making. bz#2741 * sshd(8): Add a ssh_config "Match final" predicate Matches in same pass as "Match canonical" but doesn't require hostname canonicalisation be enabled. bz#2906 * sftp(1): Support a prefix of '@' to suppress echo of sftp batch commands; bz#2926 * ssh-keygen(1): When printing certificate contents using "ssh-keygen -Lf /path/certificate", include the algorithm that the CA used to sign the cert. Bugfixes -------- * sshd(8): Fix authentication failures when sshd_config contains "AuthenticationMethods any" inside a Match block that overrides a more restrictive default. * sshd(8): Avoid sending duplicate keepalives when ClientAliveCount is enabled. * sshd(8): Fix two race conditions related to SIGHUP daemon restart. Remnant file descriptors in recently-forked child processes could block the parent sshd's attempt to listen(2) to the configured addresses. Also, the restarting parent sshd could exit before any child processes that were awaiting their re-execution state had completed reading it, leaving them in a fallback path. * ssh(1): Fix stdout potentially being redirected to /dev/null when ProxyCommand=- was in use. * sshd(8): Avoid sending SIGPIPE to child processes if they attempt to write to stderr after their parent processes have exited; bz#2071 * ssh(1): Fix bad interaction between the ssh_config ConnectTimeout and ConnectionAttempts directives - connection attempts after the first were ignoring the requested timeout; bz#2918 * ssh-keyscan(1): Return a non-zero exit status if no keys were found; bz#2903 * scp(1): Sanitize scp filenames to allow UTF-8 characters without terminal control sequences; bz#2434 * sshd(8): Fix confusion between ClientAliveInterval and time-based RekeyLimit that could cause connections to be incorrectly closed. bz#2757 * ssh(1), ssh-add(1): Correct some bugs in PKCS#11 token PIN handling at initial token login. The attempt to read the PIN could be skipped in some cases, particularly on devices with integrated PIN readers. This would lead to an inability to retrieve keys from these tokens. bz#2652 * ssh(1), ssh-add(1): Support keys on PKCS#11 tokens that set the CKA_ALWAYS_AUTHENTICATE flag by requring a fresh login after the C_SignInit operation. bz#2638 * ssh(1): Improve documentation for ProxyJump/-J, clarifying that local configuration does not apply to jump hosts. * ssh-keygen(1): Clarify manual - ssh-keygen -e only writes public keys, not private. * ssh(1), sshd(8): be more strict in processing protocol banners, allowing \r characters only immediately before \n. * Various: fix a number of memory leaks, including bz#2942 and bz#2938 * scp(1), sftp(1): fix calculation of initial bandwidth limits. Account for bytes written before the timer starts and adjust the schedule on which recalculations are performed. Avoids an initial burst of traffic and yields more accurate bandwidth limits; bz#2927 * sshd(8): Only consider the ext-info-c extension during the initial key eschange. It shouldn't be sent in subsequent ones, but if it is present we should ignore it. This prevents sshd from sending a SSH_MSG_EXT_INFO for REKEX for buggy these clients. bz#2929 * ssh-keygen(1): Clarify manual that ssh-keygen -F (find host in authorized_keys) and -R (remove host from authorized_keys) options may accept either a bare hostname or a [hostname]:port combo. bz#2935 * ssh(1): Don't attempt to connect to empty SSH_AUTH_SOCK; bz#2936 * sshd(8): Silence error messages when sshd fails to load some of the default host keys. Failure to load an explicitly-configured hostkey is still an error, and failure to load any host key is still fatal. pr/103 * ssh(1): Redirect stderr of ProxyCommands to /dev/null when ssh is started with ControlPersist; prevents random ProxyCommand output from interfering with session output. * ssh(1): The ssh client was keeping a redundant ssh-agent socket (leftover from authentication) around for the life of the connection; bz#2912 * sshd(8): Fix bug in HostbasedAcceptedKeyTypes and PubkeyAcceptedKeyTypes options. If only RSA-SHA2 siganture types were specified, then authentication would always fail for RSA keys as the monitor checks only the base key (not the signature algorithm) type against *AcceptedKeyTypes. bz#2746 * ssh(1): Request correct signature types from ssh-agent when certificate keys and RSA-SHA2 signatures are in use. Portability ----------- * sshd(8): On Cygwin, run as SYSTEM where possible, using S4U for token creation if it supports MsV1_0 S4U Logon. * sshd(8): On Cygwin, use custom user/group matching code that respects the OS' behaviour of case-insensitive matching. * sshd(8): Don't set $MAIL if UsePAM=yes as PAM typically specifies the user environment if it's enabled; bz#2937 * sshd(8) Cygwin: Change service name to cygsshd to avoid collision with Microsoft's OpenSSH port. * Allow building against OpenSSL -dev (3.x) * Fix a number of build problems against version configurations and versions of OpenSSL. Including bz#2931 and bz#2921 * Improve warnings in cygwin service setup. bz#2922 * Remove hardcoded service name in cygwin setup. bz#2922 Checksums: ========== - SHA1 (openssh-8.0.tar.gz) = 8aaa99091fc7e5a92a4a320e1e5521046b3f95f0 - SHA256 (openssh-8.0.tar.gz) = 1xvSJk1KYSnOLPYEUzyCVwTEQ7MHOaCO65DzeNuuLdo= - SHA1 (openssh-8.0p1.tar.gz) = 756dbb99193f9541c9206a667eaa27b0fa184a4f - SHA256 (openssh-8.0p1.tar.gz) = vZQ4eeaUmOgDHra39E0IzcN9WaeraJqgtDcyDDSB/Wg= Please note that the SHA256 signatures are base64 encoded and not hexadecimal (which is the default for most checksum tools). The PGP key used to sign the releases is available as RELEASE_KEY.asc from the mirror sites. Reporting Bugs: =============== - Please read http://www.openssh.com/report.html Security bugs should be reported directly to openssh@openssh.com
Posted Apr 18, 2019 22:26 UTC (Thu)
by epa (subscriber, #39769)
[Link] (6 responses)
Posted Apr 18, 2019 22:51 UTC (Thu)
by k8to (guest, #15413)
[Link] (1 responses)
Posted Apr 19, 2019 1:33 UTC (Fri)
by epa (subscriber, #39769)
[Link]
Posted Apr 19, 2019 0:01 UTC (Fri)
by perennialmind (guest, #45817)
[Link] (3 responses)
Putty's PSCP does what you describe: it has a
Posted Apr 21, 2019 0:49 UTC (Sun)
by scientes (guest, #83068)
[Link] (2 responses)
Posted Apr 21, 2019 5:17 UTC (Sun)
by lkundrak (subscriber, #43452)
[Link]
Why is it stupid?
Posted Apr 21, 2019 9:15 UTC (Sun)
by Darkmere (subscriber, #53695)
[Link]
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.
Posted Apr 18, 2019 22:57 UTC (Thu)
by k8to (guest, #15413)
[Link] (1 responses)
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.
Posted Apr 19, 2019 1:12 UTC (Fri)
by epa (subscriber, #39769)
[Link]
Posted Apr 20, 2019 1:53 UTC (Sat)
by bmur (guest, #52954)
[Link] (20 responses)
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.
Posted Apr 20, 2019 7:05 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (8 responses)
I don't remember the last time I used "cp" to perform a recursive copy... locally.
Posted Apr 20, 2019 7:16 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (7 responses)
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.
Posted Apr 20, 2019 11:06 UTC (Sat)
by dw (subscriber, #12017)
[Link] (5 responses)
Posted Apr 20, 2019 17:47 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
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.
Posted Apr 20, 2019 22:11 UTC (Sat)
by karkhaz (subscriber, #99844)
[Link] (3 responses)
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
when dst exists
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)?
Posted Apr 22, 2019 9:12 UTC (Mon)
by oldtomas (guest, #72579)
[Link]
"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"
Posted Apr 26, 2019 21:43 UTC (Fri)
by naptastic (guest, #60139)
[Link] (1 responses)
Posted Apr 26, 2019 23:49 UTC (Fri)
by karkhaz (subscriber, #99844)
[Link]
Posted Apr 22, 2019 22:09 UTC (Mon)
by Pc5Y9sbv (guest, #41328)
[Link]
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.
Posted Apr 24, 2019 10:44 UTC (Wed)
by nilsmeyer (guest, #122604)
[Link] (10 responses)
Posted Apr 24, 2019 11:39 UTC (Wed)
by gevaerts (subscriber, #21521)
[Link]
Posted Apr 27, 2019 22:49 UTC (Sat)
by naptastic (guest, #60139)
[Link] (8 responses)
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
Posted Apr 28, 2019 20:34 UTC (Sun)
by muwlgr (guest, #35359)
[Link]
Posted Apr 29, 2019 22:04 UTC (Mon)
by ScottMinster (subscriber, #67541)
[Link] (6 responses)
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.
Posted Apr 30, 2019 7:01 UTC (Tue)
by mbunkus (subscriber, #87248)
[Link] (5 responses)
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
Posted Apr 30, 2019 12:45 UTC (Tue)
by ScottMinster (subscriber, #67541)
[Link] (2 responses)
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?
Posted Apr 30, 2019 14:46 UTC (Tue)
by excors (subscriber, #95769)
[Link]
rsync -e 'ssh -X' --rsync-path='SUDO_ASKPASS=/usr/bin/ssh-askpass /usr/bin/sudo -A /usr/bin/rsync' -a server1:/path server2:/path
Posted Apr 30, 2019 14:59 UTC (Tue)
by mbunkus (subscriber, #87248)
[Link]
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.
Posted Apr 30, 2019 15:07 UTC (Tue)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Apr 30, 2019 15:14 UTC (Tue)
by mbunkus (subscriber, #87248)
[Link]
OpenSSH 8.0 released
OpenSSH 8.0 released
OpenSSH 8.0 released
OpenSSH 8.0 released
-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.
This
This
This
OpenSSH 8.0 released
In scp, I can do
OpenSSH 8.0 released
OpenSSH 8.0 released
OpenSSH 8.0 released
OpenSSH 8.0 released
cp -r src/ dst/
OpenSSH 8.0 released
OpenSSH 8.0 released
OpenSSH 8.0 released
rsync -a src/ dst --> creates dst, copies contents of src into dst
rsync -a src dst --> creates dst, copies src into dst
rsync -a src/ dst --> copies contents of src into dst
rsync -a src dst --> copies src into dst
OpenSSH 8.0 released
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 mnemonic
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
OpenSSH 8.0 released
OpenSSH 8.0 released
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?
OpenSSH 8.0 released
OpenSSH 8.0 released
OpenSSH 8.0 released
OpenSSH 8.0 released
PermitRootLogin prohibit-password
OpenSSH 8.0 released
OpenSSH 8.0 released
OpenSSH 8.0 released
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.
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