OpenSSH 9.0 released
We consider the removal of the need for double-quoting shell characters in file names to be a benefit and do not intend to introduce bug-compatibility for legacy scp/rcp in scp(1) when using the SFTP protocol.
From: | Damien Miller <djm-AT-cvs.openbsd.org> | |
To: | openssh-unix-dev-AT-mindrot.org | |
Subject: | Announce: OpenSSH 9.0 released | |
Date: | Thu, 07 Apr 2022 20:12:04 -0600 | |
Message-ID: | <[email protected]> |
OpenSSH 9.0 has just been released. It will be available from the mirrors listed at https://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: https://www.openssh.com/donations.html Changes since OpenSSH 8.9 ========================= This release is focused on bug fixing. Potentially-incompatible changes -------------------------------- This release switches scp(1) from using the legacy scp/rcp protocol to using the SFTP protocol by default. Legacy scp/rcp performs wildcard expansion of remote filenames (e.g. "scp host:* .") through the remote shell. This has the side effect of requiring double quoting of shell meta-characters in file names included on scp(1) command-lines, otherwise they could be interpreted as shell commands on the remote side. This creates one area of potential incompatibility: scp(1) when using the SFTP protocol no longer requires this finicky and brittle quoting, and attempts to use it may cause transfers to fail. We consider the removal of the need for double-quoting shell characters in file names to be a benefit and do not intend to introduce bug-compatibility for legacy scp/rcp in scp(1) when using the SFTP protocol. Another area of potential incompatibility relates to the use of remote paths relative to other user's home directories, for example - "scp host:~user/file /tmp". The SFTP protocol has no native way to expand a ~user path. However, sftp-server(8) in OpenSSH 8.7 and later support a protocol extension "[email protected]" to support this. In case of incompatibility, the scp(1) client may be instructed to use the legacy scp/rcp using the -O flag. New features ------------ * ssh(1), sshd(8): use the hybrid Streamlined NTRU Prime + x25519 key exchange method by default ("[email protected]"). The NTRU algorithm is believed to resist attacks enabled by future quantum computers and is paired with the X25519 ECDH key exchange (the previous default) as a backstop against any weaknesses in NTRU Prime that may be discovered in the future. The combination ensures that the hybrid exchange offers at least as good security as the status quo. We are making this change now (i.e. ahead of cryptographically- relevant quantum computers) to prevent "capture now, decrypt later" attacks where an adversary who can record and store SSH session ciphertext would be able to decrypt it once a sufficiently advanced quantum computer is available. * sftp-server(8): support the "copy-data" extension to allow server- side copying of files/data, following the design in draft-ietf-secsh-filexfer-extensions-00. bz2948 * sftp(1): add a "cp" command to allow the sftp client to perform server-side file copies. Bugfixes -------- * ssh(1), sshd(8): upstream: fix poll(2) spin when a channel's output fd closes without data in the channel buffer. bz3405 and bz3411 * sshd(8): pack pollfd array in server listen/accept loop. Could cause the server to hang/spin when MaxStartups > RLIMIT_NOFILE * ssh-keygen(1): avoid NULL deref via the find-principals and check-novalidate operations. bz3409 and GHPR#307 respectively. * scp(1): fix a memory leak in argument processing. bz3404 * sshd(8): don't try to resolve ListenAddress directives in the sshd re-exec path. They are unused after re-exec and parsing errors (possible for example if the host's network configuration changed) could prevent connections from being accepted. * sshd(8): when refusing a public key authentication request from a client for using an unapproved or unsupported signature algorithm include the algorithm name in the log message to make debugging easier. Portability ----------- * sshd(8): refactor platform-specific locked account check, fixing an incorrect free() on platforms with both libiaf and shadow passwords (probably only Unixware) GHPR#284, * ssh(1), sshd(8): Fix possible integer underflow in scan_scaled(3) parsing of K/M/G/etc quantities. bz#3401. * sshd(8): provide killpg implementation (mostly for Tandem NonStop) GHPR#301. * Check for missing ftruncate prototype. GHPR#301 * sshd(8): default to not using sandbox when cross compiling. On most systems poll(2) does not work when the number of FDs is reduced with setrlimit, so assume it doesn't when cross compiling and we can't run the test. bz#3398. * sshd(8): allow ppoll_time64 in seccomp sandbox. Should fix sandbox violations on some (at least i386 and armhf) 32bit Linux platforms. bz#3396. * Improve detection of -fzero-call-used-regs=all support in configure script. Checksums: ========== - SHA1 (openssh-9.0.tar.gz) = 05302aa4781e1a69db4261474ed940bd685afc24 - SHA256 (openssh-9.0.tar.gz) = 9I/FrLf5Gij/4NIPts9A8yWVi0ienyyMqjqn8s0hyLk= - SHA1 (openssh-9.0p1.tar.gz) = 06dd658874dcd22d66311cf5999bd56c614de509 - SHA256 (openssh-9.0p1.tar.gz) = A5dDAhYenszjIVPPoQAS8eZcjzdQ9XOnOrG+/Vlyooo= 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 from the mirror sites: https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/RELEASE_KEY.asc Please note that the OpenPGP key used to sign releases has been rotated for this release. The new key has been signed by the previous key to provide continuity. Reporting Bugs: =============== - Please read https://www.openssh.com/report.html Security bugs should be reported directly to [email protected]
Posted Apr 8, 2022 18:08 UTC (Fri)
by cjwatson (subscriber, #7322)
[Link] (11 responses)
Rarely have I looked forward more to a compatibility break. I've lost count of the number of times I've had to argue with scp's obtuse traditional quoting rules.
Posted Apr 9, 2022 12:58 UTC (Sat)
by cyperpunks (subscriber, #39406)
[Link] (10 responses)
Posted Apr 9, 2022 13:56 UTC (Sat)
by champtar (subscriber, #128673)
[Link] (2 responses)
Posted Apr 9, 2022 21:00 UTC (Sat)
by gerdesj (subscriber, #5446)
[Link]
Posted Apr 21, 2022 15:05 UTC (Thu)
by mrugiero (guest, #153040)
[Link]
Posted Apr 10, 2022 20:16 UTC (Sun)
by j0057 (subscriber, #143939)
[Link] (6 responses)
Posted Apr 10, 2022 21:25 UTC (Sun)
by farnz (subscriber, #17727)
[Link] (5 responses)
The way -a is documented is an example of how it's really difficult to write documentation that's both clear to newcomers and concise for experts.
When you look further down (I have 3.2.3 from Aug 2020), it says:
This is much clearer if you're not used to rsync, but a lot less concise - it tries to explain the effect of -rlptgoD but not -H -A -X. If you're an expert user just re-checking the options, though, you'd see the -rlptgoD bit and mentally expand it to: --archive does all the things you'd expect if you're using rsync as a rcp replacement - it handles directories recursively, it copies symlinks as symlinks, it preserves permissions, mtime, group and owner, and it correctly handles Devices and special files, but it does not attempt to copy Hard links as hard links, ACLs or Xattrs.
Posted Apr 10, 2022 23:43 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link]
Posted Apr 11, 2022 0:24 UTC (Mon)
by pabs (subscriber, #43278)
[Link] (3 responses)
rsync really needs a --mirror option that would make both sides identical in everything.
Posted Apr 14, 2022 19:40 UTC (Thu)
by nix (subscriber, #2304)
[Link] (2 responses)
It needs to be able to copy the attributes settable via chattr(1) first, and apparently this will never happen. This is a bit annoying to those of us who use rsync to keep whole machines synced with a master on a bigger system and would like to chattr some parts of the tree :(
Posted Apr 15, 2022 1:27 UTC (Fri)
by pabs (subscriber, #43278)
[Link] (1 responses)
Posted Jun 3, 2022 16:44 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Apr 8, 2022 18:15 UTC (Fri)
by cpacejo (subscriber, #153871)
[Link] (4 responses)
Posted Apr 8, 2022 19:47 UTC (Fri)
by marduk (subscriber, #3831)
[Link]
As far as tilde "~" expansion I think they are saying that it's not part of the protocol and worked "by accident" do to the server-side shell expansion but if the server is running 8.7+ and has the appropriate extension enabled then it will still work.
Posted Apr 8, 2022 21:38 UTC (Fri)
by bof (subscriber, #110741)
[Link] (1 responses)
Posted Apr 9, 2022 1:19 UTC (Sat)
by floppus (guest, #137245)
[Link]
Without -s, rsync uses the remote shell's filename expansion (which I think is the same as scp.)
With -s (the supposedly safer option), the behavior is *less* predictable. Suppose the remote host has two files, named 'a\b' (a backslash b) and 'a\\b' (a backslash backslash b). Then:
"rsync -s 'host:a\b' ." will copy 'a\b': the backslash is literal.
"rsync -s 'host:a\\b' ." will copy 'a\\b': both backslashes are literal.
"rsync -s 'host:a\\*b' ." will copy both 'a\b' and 'a\\b': because the argument contains a star, backslashes are treated as escapes.
Posted Apr 8, 2022 23:58 UTC (Fri)
by cjwatson (subscriber, #7322)
[Link]
Posted Apr 8, 2022 21:37 UTC (Fri)
by dullfire (guest, #111432)
[Link] (6 responses)
So they are trying to replace something tried and true, with something that was never even standardized?
Posted Apr 8, 2022 21:58 UTC (Fri)
by atnot (subscriber, #124910)
[Link]
Posted Apr 8, 2022 23:29 UTC (Fri)
by k8to (guest, #15413)
[Link]
sftp isn't really my dream utility, but my use of Linux and Unix tools has steadiliy drifted towards "making do wih stuff in the default install" instead of "installing very user-friendly tools". For better or worse.
Posted Apr 8, 2022 23:57 UTC (Fri)
by cjwatson (subscriber, #7322)
[Link] (1 responses)
Some may remember the scp security fix from OpenSSH 8.0, which had pretty much no alternative within the traditional protocol but to break some workflows due to that protocol's reliance on wildcard expansion by the remote shell. The mere fact that the remote shell's parsing rules even had to be involved in copying files should give you the willies about how scp used to work ...
PuTTY's pscp has used the SFTP protocol for years, incidentally.
Posted Apr 9, 2022 12:07 UTC (Sat)
by dtucker (subscriber, #6575)
[Link]
It dates back further than that to 4.2BSD's rcp in 1982. In OpenBSD they were almost identical codebases and we used to apply fixes to both scp.c and rcp.c (until rcp was deleted from the tree).
In fact the in the original release of ssh-1.0.0 scp.c still had a CVS Id for rcp.c, which based on the ID seems to have been sourced from FreeBSD.
Posted Apr 11, 2022 7:05 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link]
But it doen's thave the weekly security bug due to shell expansion trickery? Which is why scp is being abandoned, since it's not really possible to fix it.
Posted Apr 11, 2022 14:48 UTC (Mon)
by flussence (guest, #85566)
[Link]
Posted Apr 9, 2022 0:16 UTC (Sat)
by cypherpunks2 (guest, #152408)
[Link] (9 responses)
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/F...
> NTRU-based cryptosystems are among the leading candidates for lattice-based post-quantum cryptography. In this work, we propose improvements to the dual attack on LWE, and as such our attack is not immediately applicable to NTRU-based cryptosystems. It is an interesting question whether ideas from this work can be adapted to similar improvements to attacks on NTRU. Specifically, there appear to be similarities between the dual attack on LWE and the so-called “hybrid attack” [How07, Wun16] on NTRU. The hybrid attack also involves enumerating over parts of the secret, and then invoking some distinguisher to determine whether a resulting vector is close to a certain constant lattice. It seems reasonable to the writers of this paper that ideas similar to those presented here can be used to reduce the running time of such attacks as well, though anything definitive would of course require further research.
Posted Apr 9, 2022 4:35 UTC (Sat)
by CoelacanthusHex (guest, #144839)
[Link] (2 responses)
Posted Apr 9, 2022 5:40 UTC (Sat)
by mkj (subscriber, #85885)
[Link]
gpg-agent might still need updating to handle rsa-sha2 signatures, but that's a different problem. https://adamheins.com/blog/ssh-agent-key-rsa
Posted Apr 10, 2022 20:37 UTC (Sun)
by aaronmdjones (subscriber, #119973)
[Link]
NTRU is for the former; ssh-keygen, ssh-agent, gpg-agent, scdaemon, and such will never see it and don't even know that you're using it.
Posted Apr 9, 2022 15:54 UTC (Sat)
by tamiko (subscriber, #115350)
[Link] (5 responses)
Posted Apr 9, 2022 16:45 UTC (Sat)
by ballombe (subscriber, #9523)
[Link] (4 responses)
Posted Apr 9, 2022 17:49 UTC (Sat)
by JoeBuck (subscriber, #2330)
[Link] (2 responses)
But we could reverse your argument: suppose that NSA has secret advanced technology to use quantum computing to break current cryptography, not quite ready yet but close. How to protect that? We wouldn't want people to switch away from algorithms that they are close to breaking. Maybe by spreading paranoia about the post-quantum crypto contest?
Posted Apr 11, 2022 12:13 UTC (Mon)
by ballombe (subscriber, #9523)
[Link] (1 responses)
Posted Apr 11, 2022 14:26 UTC (Mon)
by Paf (subscriber, #91811)
[Link]
Posted Apr 9, 2022 19:42 UTC (Sat)
by cypherpunks2 (guest, #152408)
[Link]
Posted Apr 21, 2022 15:10 UTC (Thu)
by mrugiero (guest, #153040)
[Link]
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
--archive, -a
This is equivalent to -rlptgoD. It is a quick way of saying you want recursion and want to preserve almost every‐
thing (with -H being a notable omission). The only exception to the above equivalence is when --files-from is
specified, in which case -r is not implied.
Note that -a does not preserve hardlinks, because finding multiply-linked files is expensive. You must separately
specify -H.
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
> The scp "protocol" is a dismal relic of SSH 1
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
https://doi.org/10.5281/zenodo.6412487
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
The NSA does not own all of the world's cryptographers and will be unlikely to succeed again at inserting a back door into a standard, since they got caught (see https://en.wikipedia.org/wiki/Dual_EC_DRBG ). Experts will be looking harder next time, and there was enough troubling analysis at that time that almost everyone rejected that algorithm.
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
OpenSSH 9.0 released
It reminds me of Apple being """"helpful"""" by making gcc a symlink to clang.