|
|
Subscribe / Log in / New account

OpenSSH 9.0 released

OpenSSH 9.0 has been released. It is claimed to be primarily a bug-fix release, but it also switches to a new, quantum-computer-proof key-exchange protocol by default and includes a number of sftp changes, some of which may create some compatibility issues (described in the announcement) with scp.

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]


to post comments

OpenSSH 9.0 released

Posted Apr 8, 2022 18:08 UTC (Fri) by cjwatson (subscriber, #7322) [Link] (11 responses)

The description at the top of this article is quite misleading. There are indeed changes to sftp (client and server) here, but those aren't what might cause compatibility issues: that comes down to a change in scp to use the sftp protocol instead of the crusty old shell-based protocol.

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.

OpenSSH 9.0 released

Posted Apr 9, 2022 12:58 UTC (Sat) by cyperpunks (subscriber, #39406) [Link] (10 responses)

scp is so weak, it should not be used at all. learn rsync, its sane.

OpenSSH 9.0 released

Posted Apr 9, 2022 13:56 UTC (Sat) by champtar (subscriber, #128673) [Link] (2 responses)

rsync is wonderful, but it needs to be installed on both side, and is not present in minimal installs. Also it means you have shell access most of the time.

OpenSSH 9.0 released

Posted Apr 9, 2022 21:00 UTC (Sat) by gerdesj (subscriber, #5446) [Link]

lol, use scp to install rsync

OpenSSH 9.0 released

Posted Apr 21, 2022 15:05 UTC (Thu) by mrugiero (guest, #153040) [Link]

Which is also true for sftp. This change broke compatibility with the remote using dropbear, as it supports real scp but not sftp.

OpenSSH 9.0 released

Posted Apr 10, 2022 20:16 UTC (Sun) by j0057 (subscriber, #143939) [Link] (6 responses)

The rsync manpage hurts my brain. It lists multiple examples with the '-av' options. What do they do? Well, '-v' or '--verbose' is easy. Then comes '-a' or '--archive', which is equivalent to, quote, "-rltpgoD (no -H, -A, -X)". That usually makes me want to avoid using rsync.

OpenSSH 9.0 released

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:


       --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.

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.

OpenSSH 9.0 released

Posted Apr 10, 2022 23:43 UTC (Sun) by NYKevin (subscriber, #129325) [Link]

IMHO, the basic problem with rsync(1) is that it doesn't know whether it wants to be a tutorial or a reference document, and so it ends up doing both things badly. It's not quite as bad as bash(1) (too long) or sudoers(5) (https://xkcd.com/1343/, see title text), but it's still not great.

OpenSSH 9.0 released

Posted Apr 11, 2022 0:24 UTC (Mon) by pabs (subscriber, #43278) [Link] (3 responses)

My go-to for rsync is -aSHAX --delete, otherwise you miss some aspects of most Linux native filesystems. In addition I expect there are still some aspects of other filesystems missing, for eg HFS+ resource forks and NTFS secondary streams.

rsync really needs a --mirror option that would make both sides identical in everything.

OpenSSH 9.0 released

Posted Apr 14, 2022 19:40 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

> rsync really needs a --mirror option that would make both sides identical in everything.

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 :(

OpenSSH 9.0 released

Posted Apr 15, 2022 1:27 UTC (Fri) by pabs (subscriber, #43278) [Link] (1 responses)

What workaround for the missing chattr support are you using?

OpenSSH 9.0 released

Posted Jun 3, 2022 16:44 UTC (Fri) by nix (subscriber, #2304) [Link]

Workaround? Not using chattr :( alas, I want to use the immutable bit heavily, and this also breaks every backup program I've ever seen whenever a file is hardlinked (those that support setting the immutable bit at all): they all restore the first link, set its attributes (including immutability), then assume they can make further hardlinks to it later on. Not without unsetting immutability around the hardlinking, you can't...

OpenSSH 9.0 released

Posted Apr 8, 2022 18:15 UTC (Fri) by cpacejo (subscriber, #153871) [Link] (4 responses)

The quoting change sounds like it will break workflows which correctly perform escaping as needed. E.g., any tool which (correctly) uses scp to transfer files with spaces in their names would now need to be changed to use this new `-O` flag. I expect lots of enterprise workflows to be broken by this. What am I missing?

OpenSSH 9.0 released

Posted Apr 8, 2022 19:47 UTC (Fri) by marduk (subscriber, #3831) [Link]

AFAICT this applies only to wildcard "*" and ~ expansion. The wildcard expansion was using the shell on the server end so originally you would have to escape it to prevent the client shell from expanding it. I interpret this to mean it now works similar to how rsync and wildcard expansion works (IOW the sftpd daemon does the expansion instead of the shell so double-quoting is not necessary). As for which method is "correct" I think is subjective but the argument is that service-side expansion is more secure than shell expansion.

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.

OpenSSH 9.0 released

Posted Apr 8, 2022 21:38 UTC (Fri) by bof (subscriber, #110741) [Link] (1 responses)

Honest, BECAUSE of scp's totally weird quoting behaviour, in all my personal "enterprise" scripting over the years, I absolutely avoided use of it. sftp, sometimes. rsync whenever it comes to file transfers. scp, never ever.

OpenSSH 9.0 released

Posted Apr 9, 2022 1:19 UTC (Sat) by floppus (guest, #137245) [Link]

rsync also has "weird" quoting, though.

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.

OpenSSH 9.0 released

Posted Apr 8, 2022 23:58 UTC (Fri) by cjwatson (subscriber, #7322) [Link]

Any such workflow had probably already been broken by OpenSSH 8.0's scp security fix and would have had to devise a workaround, probably involving switching to something with better-specified semantics.

OpenSSH 9.0 released

Posted Apr 8, 2022 21:37 UTC (Fri) by dullfire (guest, #111432) [Link] (6 responses)

Am I just missing something? It looks like sftp only ever made it to rfc-draft stage.

So they are trying to replace something tried and true, with something that was never even standardized?

OpenSSH 9.0 released

Posted Apr 8, 2022 21:58 UTC (Fri) by atnot (subscriber, #124910) [Link]

The scp protocol is also not standardized. It less "tried and true" and more "regretful and known to be broken".

OpenSSH 9.0 released

Posted Apr 8, 2022 23:29 UTC (Fri) by k8to (guest, #15413) [Link]

sftp is sometimes annoying to use. scp is sometimes annoying to use. One of these has a lot more "unpleasant surprise" problems that can lead to security problems.

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.

OpenSSH 9.0 released

Posted Apr 8, 2022 23:57 UTC (Fri) by cjwatson (subscriber, #7322) [Link] (1 responses)

I wouldn't get too distracted by the IETF standards status here. The scp "protocol" is a dismal relic of SSH 1, before all the modern SSH protocol work, and because of the way it relied on calling scp on the remote end it was nearly impossible to extend sensibly.

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.

OpenSSH 9.0 released

Posted Apr 9, 2022 12:07 UTC (Sat) by dtucker (subscriber, #6575) [Link]

> The scp "protocol" is a dismal relic of SSH 1

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.

OpenSSH 9.0 released

Posted Apr 11, 2022 7:05 UTC (Mon) by LtWorf (subscriber, #124958) [Link]

> It looks like sftp only ever made it to rfc-draft stage.

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.

OpenSSH 9.0 released

Posted Apr 11, 2022 14:48 UTC (Mon) by flussence (guest, #85566) [Link]

I don't think everyone's security should be predicated by what a piece of paper owned by a third party says. FIPS is also a standard, but nobody in their right mind waits around for it.

OpenSSH 9.0 released

Posted Apr 9, 2022 0:16 UTC (Sat) by cypherpunks2 (guest, #152408) [Link] (9 responses)

The addition of NTRU Prime for PQC is a little premature, because a new paper just came out which showed that many LWE schemes are weaker than was previously thought. The paper admits that it is not directly applicable to NTRU (which is not an LWE scheme), but it might be adaptable to it.

https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/F...
https://doi.org/10.5281/zenodo.6412487

> 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.

OpenSSH 9.0 released

Posted Apr 9, 2022 4:35 UTC (Sat) by CoelacanthusHex (guest, #144839) [Link] (2 responses)

And it seems that there are other problems here. If you are using gpg-agent, and OpenSSH matches the NTRU algorithm, gpg-agent will refuse because it does not support the algorithm, which makes it unusable. Now OpenSSH uses this algorithm as the first choice. This makes the probability of encountering this problem greatly increased.

OpenSSH 9.0 released

Posted Apr 9, 2022 5:40 UTC (Sat) by mkj (subscriber, #85885) [Link]

I don't see how gpg-agent would see anything about NTRU, have you seen it as a problem? sntrup761x25519 should only be getting used for key exchange (KEX), versus gpg-agent which doesn't handle KEX, just public key auth signatures which keep using existing schemes.

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

OpenSSH 9.0 released

Posted Apr 10, 2022 20:37 UTC (Sun) by aaronmdjones (subscriber, #119973) [Link]

You are confusing key exchange (the algorithm that derives the encryption and authentication keys for the underlying traffic) with authentication.

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.

OpenSSH 9.0 released

Posted Apr 9, 2022 15:54 UTC (Sat) by tamiko (subscriber, #115350) [Link] (5 responses)

At least the way how sntrup761 is combined with x25519 ensures that the hybrid kex scheme does not degrade the security level of x25519.

OpenSSH 9.0 released

Posted Apr 9, 2022 16:45 UTC (Sat) by ballombe (subscriber, #9523) [Link] (4 responses)

Yes. The paranoid in me cannot help but wonder whether the NIST post-quantum crypto contest is not a sneaky attempt by the NSA to divert people from safe EC crypto to something less studied where they are more likely to have an edge.

OpenSSH 9.0 released

Posted Apr 9, 2022 17:49 UTC (Sat) by JoeBuck (subscriber, #2330) [Link] (2 responses)

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.

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?

OpenSSH 9.0 released

Posted Apr 11, 2022 12:13 UTC (Mon) by ballombe (subscriber, #9523) [Link] (1 responses)

Sorry but the the NIST competition is a major force toward the use of post-quantum crypto.

OpenSSH 9.0 released

Posted Apr 11, 2022 14:26 UTC (Mon) by Paf (subscriber, #91811) [Link]

Yes, that’s exactly the point being made. It is a force for that and so spreading uncertainty about it helps an agency that doesn’t want that transition to occur. Not saying you’re doing that but the point is the logic can go in either direction. (Which doesn’t mean it’s wrong, I think it just means we don’t know.)

OpenSSH 9.0 released

Posted Apr 9, 2022 19:42 UTC (Sat) by cypherpunks2 (guest, #152408) [Link]

We already know for a fact that ECC is broken. All that's stopping it from being broken in practice is quantum error correction and coherence times. And I would hope that we would use a hybrid key exchange in TLS and all major protocols for a long time but not because of a backdoor so much as possible weaknesses in relatively new algorithms.

OpenSSH 9.0 released

Posted Apr 21, 2022 15:10 UTC (Thu) by mrugiero (guest, #153040) [Link]

If they wanted to discourage use of scp they should just have dropped the command and forced the user to call sftp instead. Now I have a command that doesn't do what it's expected to do, which is using the scp protocol for file transfer, and breaks compatibility with other implementations in the process (as mentioned in a different comment, you'd need to explictly install the sftp-server now if you use dropbear, which seems like a drag for the use case of keeping disk and RAM usage low).
It reminds me of Apple being """"helpful"""" by making gcc a symlink to clang.


Copyright © 2022, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds