|
|
Subscribe / Log in / New account

OpenSSH 7.8 released

OpenSSH 7.8 is out. It includes a fix for the username enumeration vulnerability; additionally, the default format for the private key file has changed, support for running ssh setuid root has been removed, a couple of new signature algorithms have been added, and more.


From:  Damien Miller <djm-AT-openbsd.org>
To:  lwn-AT-lwn.net
Subject:  Announce: OpenSSH 7.8 released
Date:  Thu, 23 Aug 2018 18:46:01 -0600 (MDT)
Message-ID:  <e0a2ea1caf6c3409@openbsd.org>

OpenSSH 7.8 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

Potentially-incompatible changes
================================

This release includes a number of changes that may affect existing
configurations:

 * ssh-keygen(1): write OpenSSH format private keys by default
   instead of using OpenSSL's PEM format. The OpenSSH format,
   supported in OpenSSH releases since 2014 and described in the
   PROTOCOL.key file in the source distribution, offers substantially
   better protection against offline password guessing and supports
   key comments in private keys. If necessary, it is possible to write
   old PEM-style keys by adding "-m PEM" to ssh-keygen's arguments
   when generating or updating a key.

 * sshd(8): remove internal support for S/Key multiple factor
   authentication. S/Key may still be used via PAM or BSD auth.

 * ssh(1): remove vestigal support for running ssh(1) as setuid. This
   used to be required for hostbased authentication and the (long
   gone) rhosts-style authentication, but has not been necessary for
   a long time. Attempting to execute ssh as a setuid binary, or with
   uid != effective uid will now yield a fatal error at runtime.

 * sshd(8): the semantics of PubkeyAcceptedKeyTypes and the similar
   HostbasedAcceptedKeyTypes options have changed. These now specify
   signature algorithms that are accepted for their respective
   authentication mechanism, where previously they specified accepted
   key types. This distinction matters when using the RSA/SHA2
   signature algorithms "rsa-sha2-256", "rsa-sha2-512" and their
   certificate counterparts. Configurations that override these
   options but omit these algorithm names may cause unexpected
   authentication failures (no action is required for configurations
   that accept the default for these options).

 * sshd(8): the precedence of session environment variables has
   changed. ~/.ssh/environment and environment="..." options in
   authorized_keys files can no longer override SSH_* variables set
   implicitly by sshd.

 * ssh(1)/sshd(8): the default IPQoS used by ssh/sshd has changed.
   They will now use DSCP AF21 for interactive traffic and CS1 for
   bulk.  For a detailed rationale, please see the commit message:
   https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh...

Changes since OpenSSH 7.7
=========================

This is primarily a bugfix release.

New Features
------------

 * ssh(1)/sshd(8): add new signature algorithms "rsa-sha2-256-cert-
   v01@openssh.com" and "rsa-sha2-512-cert-v01@openssh.com" to
   explicitly force use of RSA/SHA2 signatures in authentication.

 * sshd(8): extend the PermitUserEnvironment option to accept a
   whitelist of environment variable names in addition to global
   "yes" or "no" settings.

 * sshd(8): add a PermitListen directive to sshd_config(5) and a 
   corresponding permitlisten= authorized_keys option that control
   which listen addresses and port numbers may be used by remote
   forwarding (ssh -R ...).

 * sshd(8): add some countermeasures against timing attacks used for
   account validation/enumeration. sshd will enforce a minimum time
   or each failed authentication attempt consisting of a global 5ms
   minimum plus an additional per-user 0-4ms delay derived from a
   host secret.

 * sshd(8): add a SetEnv directive to allow an administrator to
   explicitly specify environment variables in sshd_config.
   Variables set by SetEnv override the default and client-specified
   environment.

 * ssh(1): add a SetEnv directive to request that the server sets
   an environment variable in the session. Similar to the existing
   SendEnv option, these variables are set subject to server
   configuration.

 * ssh(1): allow "SendEnv -PATTERN" to clear environment variables
   previously marked for sending to the server. bz#1285

 * ssh(1)/sshd(8): make UID available as a %-expansion everywhere
   that the username is available currently. bz#2870

 * ssh(1): allow setting ProxyJump=none to disable ProxyJump
   functionality. bz#2869

Bugfixes
--------

 * sshd(8): avoid observable differences in request parsing that could
   be used to determine whether a target user is valid.

 * all: substantial internal refactoring

 * ssh(1)/sshd(8): fix some memory leaks; bz#2366

 * ssh(1): fix a pwent clobber (introduced in openssh-7.7) that could
   occur during key loading, manifesting as crash on some platforms.

 * sshd_config(5): clarify documentation for AuthenticationMethods
   option; bz#2663

 * ssh(1): ensure that the public key algorithm sent in a
   public key SSH_MSG_USERAUTH_REQUEST matches the content of the
   signature blob. Previously, these could be inconsistent when a
   legacy or non-OpenSSH ssh-agent returned a RSA/SHA1 signature
   when asked to make a RSA/SHA2 signature.

 * sshd(8): fix failures to read authorized_keys caused by faulty
   supplemental group caching. bz#2873

 * scp(1): apply umask to directories, fixing potential mkdir/chmod
   race when copying directory trees bz#2839

 * ssh-keygen(1): return correct exit code when searching for and
   hashing known_hosts entries in a single operation; bz#2772

 * ssh(1): prefer the ssh binary pointed to via argv[0] to $PATH when
   re-executing ssh for ProxyJump. bz#2831

 * sshd(8): do not ban PTY allocation when a sshd session is
   restricted because the user password is expired as it breaks
   password change dialog. (regression in openssh-7.7).

 * ssh(1)/sshd(8): fix error reporting from select() failures. 

 * ssh(1): improve documentation for -w (tunnel) flag, emphasising
   that -w implicitly sets Tunnel=point-to-point. bz#2365

 * ssh-agent(1): implement EMFILE mitigation for ssh-agent. ssh-agent
   will no longer spin when its file descriptor limit is exceeded.
   bz#2576

 * ssh(1)/sshd(8): disable SSH2_MSG_DEBUG messages for Twisted Conch
   clients. Twisted Conch versions that lack a version number in
   their identification strings will mishandle these messages when
   running on Python 2.x (https://twistedmatrix.com/trac/ticket/9422)

 * sftp(1): notify user immediately when underlying ssh process dies
   expectedly. bz#2719

 * ssh(1)/sshd(8): fix tunnel forwarding; regression in 7.7 release.
   bz#2855

 * ssh-agent(1): don't kill ssh-agent's listening socket entirely if
   it fails to accept(2) a connection. bz#2837

 * sshd(8): relax checking of authorized_keys environment="..."
   options to allow underscores in variable names (regression
   introduced in 7.7). bz#2851

 * ssh(1): add some missing options in the configuration dump output
   (ssh -G). bz#2835

Portability
-----------

 * sshd(8): Expose details of completed authentication to PAM auth
   modules via SSH_AUTH_INFO_0 in the PAM environment. bz#2408

 * Fix compilation problems caused by fights between zlib and OpenSSL
   colliding uses of "free_func"

 * Improve detection of unsupported compiler options. Recently these
   may have manifested as "unsupported -Wl,-z,retpoline" warnings
   during linking.

 * sshd(8): some sandbox support for Linux/s390 bz#2752.

 * regress tests: unbreak key-options.sh test on platforms without
   openpty(3). bz#2856

 * use getrandom(2) for PRNG seeding when built without OpenSSL.

Checksums:
==========

- SHA1 (openssh-7.8.tar.gz) = ed5511cd42b543cd15166a9cbc56705f23b847e7
- SHA256 (openssh-7.8.tar.gz) = TDqIsMEmghsBUNCrSCPyCxChfitntyOLXNC694py1XE

- SHA1 (openssh-7.8p1.tar.gz) = 27e267e370315561de96577fccae563bc2c37a60
- SHA256 (openssh-7.8p1.tar.gz) = GkhLsVFSwYO7JRThEqow3TQTjDz7Ay7uVJCmbFBxRMo

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


to post comments

Private key encryption change

Posted Aug 24, 2018 21:35 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (15 responses)

For the key format change (which anybody reading LWN should probably go fix now, takes like two minutes) It seems fairly reasonable to credit:

https://latacora.singles/2018/08/03/the-default-openssh.html

I'm not clear on whether it's Latacora policy not to credit individuals on that blog, or in fact Latacora is primarily a single person, or what.

But it seems like the overwhelming responses to it were:

1. Well, but I don't really see how this is worse than plaintext? Oh, I see. Well, I guess that's not great news.
2. Why the heck doesn't OpenSSH do this by default for, say, the last several years?
3. OK, I buy your explanation for why some people won't want this, but, again, _default_? Why have a default that supports crazy people but makes everybody else's security worse?

All of which screams "Change the default" or preferably "Go back in time, and change the default weeks ago" but time machines are not available to the OpenSSH team.

Private key encryption change

Posted Aug 25, 2018 4:49 UTC (Sat) by k8to (guest, #15413) [Link] (1 responses)

Remembering where you parked the time machine is always a bother. A future copy of yourself might have taken it first.

Private key encryption change

Posted Aug 26, 2018 1:44 UTC (Sun) by gus3 (guest, #61103) [Link]

But that future copy of me left another copy of the machine somewhere else.

Which simplifies the solution domain, but renders the problem domain much more complex. Kind of like grep and Perl.

Private key encryption change

Posted Aug 25, 2018 13:04 UTC (Sat) by ScienceMan (subscriber, #122508) [Link] (9 responses)

Just a short note to endorse the above in its entirety. For me it took a few more minutes to read the documentation and the post, try out "ssh-keygen -p -o -f KEYFILE" on an example RSA test key to verify that it did as advertised let me leave the legacy RSA public key untouched while upgrading the private key to the openssh new default format, verify in a test setting that I could use this with any key agent I needed to fire up, and thus resolve to upgrade all of my legacy keys using this procedure.

People reading this who need to keep their existing RSA public keys working until they can look into other methods while avoiding having nasty hackable private keys laying around should do this right away. Read the documentation if you want to find out what this is doing, and compare the public and private keys before and after the procedure if you want peace of mind that you have in fact done a Good Thing (TM). You might as well upgrade your password to something longer and less guessable along the way.

Private key encryption change

Posted Aug 27, 2018 10:44 UTC (Mon) by gdt (subscriber, #6284) [Link] (8 responses)

You might as well upgrade your password to something longer and less guessable along the way.

Can I suggest that passwords are no longer fit for purpose. Even 40-odd bits of randomness for a "poor" password pushes human limits (eg: IRYgxNV) and 80-odd bits easily exceeds those limits (eg: X7g6zCi2xqKbKzV9). I'm not that comfortable with security recommendations which require beyond-human performance to meet, especially if those recommendations then implicitly criticise people for being human.

Could I suggest that we begin to recommend hardware tokens for authentication? And where services don't support tokens themselves that we suggest a password manager and that access to it be secured by a hardware token?

I've got hopes for U2F FIDO2 as a primary source of authentication which displaces passwords. We'll see.

Private key encryption change

Posted Aug 27, 2018 10:53 UTC (Mon) by cagrazia (guest, #124754) [Link] (5 responses)

> Even 40-odd bits of randomness for a "poor" password pushes human limits (eg: IRYgxNV) and 80-odd bits easily exceeds those limits (eg: X7g6zCi2xqKbKzV9)

Relevant XKCD: https://xkcd.com/936/

Private key encryption change

Posted Aug 27, 2018 11:06 UTC (Mon) by gdt (subscriber, #6284) [Link] (2 responses)

I would suggest the ability to choose "four random common words" is also beyond human capability. There's no shortage of psychology papers suggesting that human can't make a random choice from 1000-or-so items, yet the xkcd algorithm relies upon such an ability for its strength.

Private key encryption change

Posted Aug 27, 2018 12:06 UTC (Mon) by karkhaz (subscriber, #99844) [Link]

I don't think this is much of an issue, as it can easily be accomplished in software. There are plenty of password managers and online passphrase generators that offer this option.

Private key encryption change

Posted Aug 27, 2018 18:07 UTC (Mon) by micka (subscriber, #38720) [Link]

You use something like diceware to create the password. With real dice. But that's an implementation detail.

Private key encryption change

Posted Aug 27, 2018 17:19 UTC (Mon) by brouhaha (subscriber, #1698) [Link]

After seeing that, I changed all of my passwords to "correct horse battery staple", since that phrase has about 44 bits of entropy.

Private key encryption change

Posted Aug 27, 2018 20:42 UTC (Mon) by epa (subscriber, #39769) [Link]

I think that comic's point is more to argue about inane 'password strength' rules that require at least one digit, at least one punctuation character, and so on. It's common to just pick a password and then add the digit 1 and possibly ! to the end to satisfy the requirements. (Some follow a predictable obfuscation scheme replacing all letter I with 1 and all E with 3, car-numberplate-style). If "best practice" requires you to change your password every thirty days, you just rotate the digit at the end...

Private key encryption change

Posted Aug 27, 2018 18:40 UTC (Mon) by brunowolff (guest, #71160) [Link] (1 responses)

> Even 40-odd bits of randomness for a "poor" password pushes human limits (eg: IRYgxNV) and 80-odd bits easily exceeds those limits (eg: X7g6zCi2xqKbKzV9).
That has not been my experience. I've found for a password that I use (i.e. type) multiple times a day, I can remember a password with 130+ bits of entropy (e.g. Q"Z@b,WQk!\#x?i#gZVv) and even remember it after short breaks (e.g. a week) from using it.

Private key encryption change

Posted Aug 28, 2018 12:46 UTC (Tue) by ledow (guest, #11753) [Link]

Can you remember two passwords of half the strength required?

Congratulations you can remember a single password of the strength required.

Human memory is not yet the limiter. But if it was then a password manager would be in order, protected by something the human has / knows. Not dumbing down to the humans.

Private key encryption change

Posted Aug 28, 2018 8:31 UTC (Tue) by joib (subscriber, #8541) [Link] (2 responses)

As a heads-up, using the new-style encrypted private keys breaks gnome-keyring (at least the version in Ubuntu 16.04, don't know if it has been fixed since). So if you get error messages when trying to ssh to some host like

sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

then it means the problem is that gnome-keyring doesn't understand the private key. One solution is to disable gnome-keyring and instead use ssh-agent.

Private key encryption change

Posted Aug 28, 2018 10:45 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (1 responses)

Current gnome-keyring (3.28 onwards at least) doesn't provide its own SSH agent, it just runs the one from OpenSSH and feeds certain keys into that agent

Private key encryption change

Posted Aug 28, 2018 19:12 UTC (Tue) by joib (subscriber, #8541) [Link]

Oh, great, that should(?) fix other long-standing issues with gnome-keyring as well, such as lack of support for ECDSA or Ed25519 keys.

FWIW, it seems the relevant bug report is https://bugzilla.gnome.org/show_bug.cgi?id=775981

OpenSSH 7.8 released

Posted Aug 27, 2018 16:03 UTC (Mon) by frostsnow (subscriber, #114957) [Link]

Related: Use the '-a #' option to increase the number of rounds in your KDF.


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