|
|
Subscribe / Log in / New account

OpenSSH 6.7 released

From:  Damien Miller <djm-AT-cvs.openbsd.org>
To:  openssh-unix-dev-AT-mindrot.org
Subject:  Announce: OpenSSH 6.7 released
Date:  Mon, 6 Oct 2014 17:16:40 -0600 (MDT)
Message-ID:  <11168654333636927008.enqueue@cvs.openbsd.org>

OpenSSH 6.7 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 version 1.3, 1.5 and 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

Changes since OpenSSH 6.6
=========================

Potentially-incompatible changes

 * sshd(8): The default set of ciphers and MACs has been altered to
   remove unsafe algorithms. In particular, CBC ciphers and arcfour*
   are disabled by default.

   The full set of algorithms remains available if configured
   explicitly via the Ciphers and MACs sshd_config options.

 * sshd(8): Support for tcpwrappers/libwrap has been removed.

 * OpenSSH 6.5 and 6.6 have a bug that causes ~0.2% of connections
   using the curve25519-sha256@libssh.org KEX exchange method to fail
   when connecting with something that implements the specification
   correctly. OpenSSH 6.7 disables this KEX method when speaking to
   one of the affected versions.

New Features

 * Major internal refactoring to begin to make part of OpenSSH usable
   as a library. So far the wire parsing, key handling and KRL code
   has been refactored. Please note that we do not consider the API
   stable yet, nor do we offer the library in separable form.

 * ssh(1), sshd(8): Add support for Unix domain socket forwarding.
   A remote TCP port may be forwarded to a local Unix domain socket
   and vice versa or both ends may be a Unix domain socket.

 * ssh(1), ssh-keygen(1): Add support for SSHFP DNS records for
   ED25519 key types.

 * sftp(1): Allow resumption of interrupted uploads.

 * ssh(1): When rekeying, skip file/DNS lookups of the hostkey if it
   is the same as the one sent during initial key exchange; bz#2154

 * sshd(8): Allow explicit ::1 and 127.0.0.1 forwarding bind
   addresses when GatewayPorts=no; allows client to choose address
   family; bz#2222

 * sshd(8): Add a sshd_config PermitUserRC option to control whether
   ~/.ssh/rc is executed, mirroring the no-user-rc authorized_keys
   option; bz#2160

 * ssh(1): Add a %C escape sequence for LocalCommand and ControlPath
   that expands to a unique identifer based on a hash of the tuple of
   (local host, remote user, hostname, port). Helps avoid exceeding
   miserly pathname limits for Unix domain sockets in multiplexing
   control paths; bz#2220

 * sshd(8): Make the "Too many authentication failures" message
   include the user, source address, port and protocol in a format
   similar to the authentication success / failure messages; bz#2199

 * Added unit and fuzz tests for refactored code. These are run
   automatically in portable OpenSSH via the "make tests" target.

Bugfixes

 * sshd(8): Fix remote forwarding with the same listen port but
   different listen address.

 * ssh(1): Fix inverted test that caused PKCS#11 keys that were
   explicitly listed in ssh_config or on the commandline not to be
   preferred.

 * ssh-keygen(1): Fix bug in KRL generation: multiple consecutive
   revoked certificate serial number ranges could be serialised to an
   invalid format. Readers of a broken KRL caused by this bug will
   fail closed, so no should-have-been-revoked key will be accepted.

 * ssh(1): Reflect stdio-forward ("ssh -W host:port ...") failures in
   exit status. Previously we were always returning 0; bz#2255

 * ssh(1), ssh-keygen(1): Make Ed25519 keys' title fit properly in the
   randomart border; bz#2247

 * ssh-agent(1): Only cleanup agent socket in the main agent process
   and not in any subprocesses it may have started (e.g. forked
   askpass). Fixes agent sockets being zapped when askpass processes
   fatal(); bz#2236

 * ssh-add(1): Make stdout line-buffered; saves partial output getting
   lost when ssh-add fatal()s part-way through (e.g. when listing keys
   from an agent that supports key types that ssh-add doesn't);
   bz#2234

 * ssh-keygen(1): When hashing or removing hosts, don't choke on
   @revoked markers and don't remove @cert-authority markers; bz#2241

 * ssh(1): Don't fatal when hostname canonicalisation fails and a
   ProxyCommand is in use; continue and allow the ProxyCommand to
   connect anyway (e.g. to a host with a name outside the DNS behind
   a bastion)

 * scp(1): When copying local->remote fails during read, don't send
   uninitialised heap to the remote end.

 * sftp(1): Fix fatal "el_insertstr failed" errors when tab-completing
   filenames with  a single quote char somewhere in the string;
   bz#2238

 * ssh-keyscan(1): Scan for Ed25519 keys by default.

 * ssh(1): When using VerifyHostKeyDNS with a DNSSEC resolver, down-
   convert any certificate keys to plain keys and attempt SSHFP
   resolution.  Prevents a server from skipping SSHFP lookup and
   forcing a new-hostkey dialog by offering only certificate keys.
     
 * sshd(8): Avoid crash at exit via NULL pointer reference; bz#2225

 * Fix some strict-alignment errors.

Portable OpenSSH

 * Portable OpenSSH now supports building against libressl-portable.

 * Portable OpenSSH now requires openssl 0.9.8f or greater. Older
   versions are no longer supported.

 * In the OpenSSL version check, allow fix version upgrades (but not
   downgrades. Debian bug #748150.

 * sshd(8): On Cygwin, determine privilege separation user at runtime,
   since it may need to be a domain account.

 * sshd(8): Don't attempt to use vhangup on Linux. It doesn't work for
   non-root users, and for them it just messes up the tty settings.

 * Use CLOCK_BOOTTIME in preference to CLOCK_MONOTONIC when it is
   available. It considers time spent suspended, thereby ensuring
   timeouts (e.g. for expiring agent keys) fire correctly.  bz#2228

 * Add support for ed25519 to opensshd.init init script.

 * sftp-server(8): On platforms that support it, use prctl() to
   prevent sftp-server from accessing /proc/self/{mem,maps}

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

 - SHA1 (openssh-6.7.tar.gz) = 315497b27a0186e4aef67987cfc9f3d9ba561cd8
 - SHA256 (openssh-6.7.tar.gz) = /me/hPxDw9Tfd3siNKQubSQph84qiKwftiMsgj6nh5E=

 - SHA1 (openssh-6.7p1.tar.gz) = 14e5fbed710ade334d65925e080d1aaeb9c85bf6
 - SHA256 (openssh-6.7p1.tar.gz) = svg5Tq6Fjau9732sELma7ADJVGJ1PoA0LlMLu29yVQc=

Please note that the PGP key used to sign releases was recently rotated.
The new key has been signed by the old key to provide continuity. It is
available from the mirror sites as RELEASE_KEY.asc.

Reporting Bugs:
===============

- Please read http://www.openssh.com/report.html
  Security bugs should be reported directly to openssh@openssh.com

OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt,
Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and
Ben Lindstrom.



to post comments

OpenSSH 6.7 released

Posted Oct 7, 2014 13:32 UTC (Tue) by pizza (subscriber, #46) [Link] (18 responses)

> * sshd(8): Support for tcpwrappers/libwrap has been removed.

This is one thing I *really* hope distros patch back in, at least until there's some equivalent replacement for denyhosts or fail2ban that's built around iptables. (which doesn't work quite so well for dynamic rules..)

OpenSSH 6.7 released

Posted Oct 7, 2014 14:20 UTC (Tue) by bersl2 (guest, #34928) [Link] (1 responses)

Yeah, that's a bit of a head-scratcher for me. Yes, there are better access control mechanisms out there, but it still works, and admins still use it. What was the rationale given for removing support? What was libwrap holding back, if anything?

OpenSSH 6.7 released

Posted Oct 7, 2014 15:03 UTC (Tue) by raven667 (subscriber, #5198) [Link]

Searching the mail archives turns up this thread announcing the intent to change, the answer is likely here

http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-...

It looks like the reason was that the Match keyword already covered this use case and it removes a dependency from the critical pre-auth code path, a library which is from a different era.

OpenSSH 6.7 released

Posted Oct 7, 2014 14:33 UTC (Tue) by raven667 (subscriber, #5198) [Link]

Famous last words(tm), "That shouldn't be very hard...". You could make a port 22 match on the INPUT filter table, using your OS provided iptables management like lokkit or firewalld or whatever, jump to an access list maintained by these rules with whatever policy they like. So fail2ban would manage its own list that doesn't interact with your OS provided iptables rules, until and unless you implement the jump rule using whatever tools are otherwise managing your rules.

OpenSSH 6.7 released

Posted Oct 7, 2014 14:39 UTC (Tue) by kh (guest, #19413) [Link]

It seems very puzzling to drop something so well tested, minimal, and in such wide use to me also...

OpenSSH 6.7 released

Posted Oct 7, 2014 14:53 UTC (Tue) by kh (guest, #19413) [Link] (2 responses)

Doesn't iptables use a lot more processor than using libwrap? I seem to remember setting up small systems with denyhosts vs iptables specifically to prevent incidental DOS from high numbers of dictionary attacks. Seems like this would be even more of an issue with all the embedded systems being deployed, not to mention making it difficult for existing small and embedded systems that might need the next big ssh security update.

OpenSSH 6.7 released

Posted Oct 7, 2014 15:17 UTC (Tue) by raven667 (subscriber, #5198) [Link] (1 responses)

No, quite the opposite, iptables can drop the frame early in the kernel, without having to complete the connection and pass the socket off to userspace and have userspace only then drop the connection. If netfilter is enabled the packets will go through it in both cases so it can't be adding any overhead than what you already have.

OpenSSH 6.7 released

Posted Oct 7, 2014 15:29 UTC (Tue) by nybble41 (subscriber, #55106) [Link]

Also, for busy sites, the use of ipsets rather than long chains of IP-specific rules can further reduce the overhead. To ban or unban an address just update the ipset--no need to change the rules at all.

OpenSSH 6.7 released

Posted Oct 7, 2014 15:02 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

See <http://marc.info/?l=openssh-unix-dev&m=13982939112129...> and the next article in that thread, which gives you 'Match exec' support in sshd (as well as ssh) and a 'Match exec' helper that uses tcp-wrappers.

OpenSSH 6.7 released

Posted Oct 8, 2014 10:44 UTC (Wed) by cjwatson (subscriber, #7322) [Link] (1 responses)

That does however not seem to have been applied in 6.7. I didn't look into the details of why not.

OpenSSH 6.7 released

Posted Oct 8, 2014 14:54 UTC (Wed) by nix (subscriber, #2304) [Link]

Probably because nobody expressed any interest.

OpenSSH 6.7 released

Posted Oct 7, 2014 16:02 UTC (Tue) by zuki (subscriber, #41808) [Link]

> This is one thing I *really* hope distros patch back in, at least until there's some equivalent replacement for denyhosts or fail2ban that's built around iptables. (which doesn't work quite so well for dynamic rules..)

What do you mean it doesn't work for dynamic rules? Try this config:
https://github.com/fail2ban/fail2ban/blob/master/config/a...

(Both fully dynamic and lightweight, and runs unprivileged too.)

OpenSSH 6.7 released

Posted Oct 8, 2014 7:12 UTC (Wed) by Yorhel (subscriber, #91403) [Link]

You mean sshguard? http://www.sshguard.net/

That's what I've been using on all my boxes.

OpenSSH 6.7 released

Posted Oct 8, 2014 10:26 UTC (Wed) by terom (guest, #55278) [Link]

pam_abl is the way to go IMO, it works just fine in Debian (libpam-abl)

No regexping of syslog lines, and leave iptables to things like low-level packet rate-limiting to protect against actually DoS'ing behaviour.

Do your auth/access control in your PAM stack, which already provides a programmatic library interface that has all the required information (username, remote host, auth success/fail).

OpenSSH 6.7 released

Posted Oct 8, 2014 10:50 UTC (Wed) by cjwatson (subscriber, #7322) [Link]

I'm going to patch it back in for now in the Debian packaging (and thence for Ubuntu etc.). I think upstream have a point, but it's a pretty disruptive change to inflict on people in one shot for upgrades, especially when I intend to try to get this into jessie shortly before a freeze. Patching it back in is straightforward enough, and I've never heard of an actual vulnerability here aside from the one 15 years ago or so where somebody released a trojaned version of tcp-wrappers, so for the moment I'm willing to accept the risk.

We (Debian) should probably consider ways to migrate people away from this more gently, though, as I don't know whether I want to carry this patch indefinitely. denyhosts has already been removed from jessie, which is a start.

OpenSSH 6.7 released

Posted Oct 9, 2014 20:04 UTC (Thu) by cdmiller (guest, #2813) [Link]

While I've had good results with iptables and xt_recent, an ntp appliance I just configured has no iptables and uses libwrap for the IP based ACL's.

OpenSSH 6.7 released

Posted Oct 10, 2014 8:00 UTC (Fri) by jsanders (subscriber, #69784) [Link] (2 responses)

Why not use pam_abl? I don't understand why this project isn't more popular.

OpenSSH 6.7 released

Posted Oct 10, 2014 14:46 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

Well for me, I've never heard of it before.

I'm not all that sure that automatic blacklisting actually does much for you except to reduce the amount of logging, if you are doing anything sensible for authentication (like key-based auth and/or two-factor) then none of the automated scans are going to work, ever, and you take on a new risk that your automatic blacklisting system will deny yourself service on your own machines. What might work better would be to audit _successful_ logins, and report on any which come from new and interesting networks, this can actually catch someone who has copied a key or passphrase, there is no point chasing after logins which you already know have been denied.

OpenSSH 6.7 released

Posted Oct 10, 2014 16:08 UTC (Fri) by JGR (subscriber, #93631) [Link]

As much as it'd be great if everyone used key and/or two factor auth for everything, passwords are here to stay.
Even if a scanner will never successfully login, there's no need to humour it by accepting silly numbers of authentication attempts, which have their own costs in bandwidth, CPU time, etc.

If a trusted machine is generating large numbers of failed authentications, then temporary blacklisting seems a perfectly valid response, even if it does stop you logging in from that machine.
If nothing else being blacklisted will signal to you/the users of a trusted machine that something seems dubious, in the absence of anyone bothering to read the logs.

Auditing successful logins is a good idea, this doesn't preclude also taking action for unsuccessful ones though.

OpenSSH 6.7 released

Posted Oct 7, 2014 21:57 UTC (Tue) by gdt (subscriber, #6284) [Link] (3 responses)

Imagine a user with a /etc/hosts.allow of

sshd: 1.2.3.0/24

and a /etc/hosts.deny of

ALL: ALL

The version of sshd moves from blocking most access to sshd to allowing all with no log messages or other warning of the change evident at run time.

I'm finding it hard to think that this is an improvement in security.

OpenSSH 6.7 released

Posted Oct 8, 2014 0:21 UTC (Wed) by NightMonkey (subscriber, #23051) [Link] (2 responses)

If I am understanding this scenario right, this version simply gives the job to other more appropriate parts of the software stack. I'm pretty sure you can do the same as you wish to do with iptables, including logging (though watch out for DoSing via log floods!).

OpenSSH 6.7 released

Posted Oct 8, 2014 6:38 UTC (Wed) by imitev (guest, #60045) [Link] (1 responses)

The way I'm reading it, the OP's complaint is that simply upgrading to the newer version without paying attention that tcp wrappers are not used anymore will allow any connection without warning, while he may think he's still only allowing connections from 1.2.3.0/24. You may see that as a regression.

Granted, one shouldn't blindly upgrade such packages, but if you have configured "automatic" updates, it will be interesting to see how distributions handle those (enterprise distros are usually stuck with one version, but users of a rolling distro might face this problem).

OpenSSH 6.7 released

Posted Oct 8, 2014 10:43 UTC (Wed) by lucke (guest, #58819) [Link]

Here's what Arch did more that 3 years ago: https://www.archlinux.org/news/dropping-tcp_wrappers-supp...

Perhaps this news message also in a way supports the decision of OpenSSH to remove tcp_wrappers support.

OpenSSH 6.7 released

Posted Oct 7, 2014 23:03 UTC (Tue) by NightMonkey (subscriber, #23051) [Link] (5 responses)

IPTables/Netfilter seems to be the right way to go. Supporting a framework that doesn't take into account more appropriate and manageable kernel features should be removed. Dropping TCPWrappers (which, as an admin, I've not advocated use of for a long time) makes sense for a F/OSS project with limited resources.

If something as 'complex' as sshuttle can work its magic with iptables rules alone, I'd think fail2ban and friends can work with just iptables. :)

Ref: https://github.com/apenwarr/sshuttle

OpenSSH 6.7 released

Posted Oct 7, 2014 23:56 UTC (Tue) by Trelane (subscriber, #56877) [Link] (4 responses)

Is there something like denyhosts for iptables?

OpenSSH 6.7 released

Posted Oct 8, 2014 0:00 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

fail2ban works with iptables.

OpenSSH 6.7 released

Posted Oct 8, 2014 4:35 UTC (Wed) by lucke (guest, #58819) [Link] (2 responses)

For all your blocking needs: http://www.sshguard.net/

OpenSSH 6.7 released

Posted Oct 8, 2014 4:38 UTC (Wed) by NightMonkey (subscriber, #23051) [Link]

Oh, man, that looks awesome. Thanks!

OpenSSH 6.7 released

Posted Oct 8, 2014 7:37 UTC (Wed) by BlueLightning (subscriber, #38978) [Link]

sshguard initially looked really good to me, but I'd be a lot more enthusiastic about it if (a) it appeared to be actively maintained (a problem it shares with fail2ban) and (b) the authors were a bit more careful with licensing of code they've incorporated.

OpenSSH 6.7 released

Posted Oct 8, 2014 0:56 UTC (Wed) by josh (subscriber, #17465) [Link] (14 responses)

The ability to forward UNIX domain sockets seems wildly useful. I'm looking forward to a variety of new applications for this, as a generalized version of "ssh -X" and "ssh -A".

OpenSSH 6.7 released

Posted Oct 8, 2014 6:57 UTC (Wed) by lkundrak (subscriber, #43452) [Link]

I guess you'll be able to forward dbus sockets and forward your dconf to remote or maybe send-notifications with notify-send once a remote job is done. Nice.

OpenSSH 6.7 released

Posted Oct 8, 2014 8:10 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (12 responses)

Forwarding the gpg agent makes it much simpler and much more useful to use smartcards for signing code, for example. And by needing both a smartcard and a smartcard PIN, you effectively get two factor authentication for free.

OpenSSH 6.7 released

Posted Oct 9, 2014 8:08 UTC (Thu) by grawity (subscriber, #80596) [Link] (2 responses)

Unfortunately, GnuPG 2.1 now hardcodes the socket path, which makes this a little bit less convenient – can't have different sockets per session anymore (as a result, if you close the 'forwarding' session, all other sessions break), and can't even use forwarded and locally-running gpg-agent from different sessions.

OpenSSH 6.7 released

Posted Oct 9, 2014 14:59 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link]

You can always use a different GNUPGHOME.

Given that not all file systems support sockets, the plan is to allow a pseudo socket file to redirect to the real socket. If you post your use-case to gnupg-devel or -users, we can see now we can help you out.

OpenSSH 6.7 released

Posted Oct 10, 2014 9:57 UTC (Fri) by pbonzini (subscriber, #60935) [Link]

"ssh -N" for the win!

OpenSSH 6.7 released

Posted Oct 9, 2014 9:06 UTC (Thu) by cortana (subscriber, #24596) [Link] (8 responses)

It is not safe to forward the connection to your GPG agent to any host you don't trust. Unless I'm mistaken and/or GPG has changed, the GPG agent works by handing the private key over to the client, and the cryptographic operations are performed on the client side. So anyone who can talk to the socket can grab your plaintext key!

OpenSSH 6.7 released

Posted Oct 9, 2014 15:04 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link] (6 responses)

No, that is not true: Before 2.1 gpg-agent acted only as a passphrase cache for gpg. With 2.1 gpg changes to behave as gpgsm has always done: Only the gpg-agent has control over your private keys and gpg receives just the session key from gpg-agent. Thus running gpg on the server and gpg-agent on your client/desktop protects your private key against a compromised server. But not the plaintext of course.

OpenSSH 6.7 released

Posted Oct 10, 2014 7:21 UTC (Fri) by kleptog (subscriber, #1183) [Link] (2 responses)

So all you need now is a dialog that says "someone is trying to sign something with key X" (Accept/Deny) and we can have nice things.

Does such a dialog exist for ssh-agent?

OpenSSH 6.7 released

Posted Oct 10, 2014 8:37 UTC (Fri) by dd9jn (✭ supporter ✭, #4459) [Link] (1 responses)

You mean ssh-add's -c option? If you use "ssh-add -c" for putting an ssh key into gpg-agent, that flag is set. If you want to change it later, you can add it to ~/.gnupg/sshcontrol.

OpenSSH 6.7 released

Posted Oct 11, 2014 10:51 UTC (Sat) by kleptog (subscriber, #1183) [Link]

Wow! Why did I not know about this option. Thanks a lot!

OpenSSH 6.7 released

Posted Oct 10, 2014 10:56 UTC (Fri) by cortana (subscriber, #24596) [Link] (2 responses)

Hmm, won't the GET_PASSPHRASE command still return me the user's passphrase?

OpenSSH 6.7 released

Posted Oct 10, 2014 13:37 UTC (Fri) by dd9jn (✭ supporter ✭, #4459) [Link] (1 responses)

GnuPG 2.1 does not use this command anymore. But you raise a good idea. There should be an option to disable this command to not help malware to trick the user into entering the passphrase.

OpenSSH 6.7 released

Posted Oct 13, 2014 8:53 UTC (Mon) by tialaramex (subscriber, #21167) [Link]

I recommend the following series of steps to get from where you are to where you would like to be with the maximum of security and minimum of inconvenience to the end users

1. Add option to disable, but default enabled for existing installs
2. Add warning when user has not made explicit choice to enable / disable
3. Change default to disabled
4. Remove warning

OpenSSH 6.7 released

Posted Oct 10, 2014 9:56 UTC (Fri) by pbonzini (subscriber, #60935) [Link]

I do trust the host. I just want to keep the private keys physically where I am.


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