OpenSSH 7.0
| From: | Damien Miller <djm-AT-cvs.openbsd.org> | |
| To: | lwn-AT-lwn.net | |
| Subject: | Announce: OpenSSH 7.0 released | |
| Date: | Tue, 11 Aug 2015 06:53:24 -0600 (MDT) | |
| Message-ID: | <9092910250448015018.enqueue@cvs.openbsd.org> |
OpenSSH 7.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. OpenSSH also includes transitional support for the legacy SSH 1.3 and 1.5 protocols that may be enabled at compile-time. 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 Future deprecation notice ========================= We plan on retiring more legacy cryptography in the next release including: * Refusing all RSA keys smaller than 1024 bits (the current minimum is 768 bits) * Several ciphers will be disabled by default: blowfish-cbc, cast128-cbc, all arcfour variants and the rijndael-cbc aliases for AES. * MD5-based HMAC algorithms will be disabled by default. This list reflects our current intentions, but please check the final release notes for OpenSSH 7.1 when it is released. Changes since OpenSSH 6.9 ========================= This focus of this release is primarily to deprecate weak, legacy and/or unsafe cryptography. Security -------- * sshd(8): OpenSSH 6.8 and 6.9 incorrectly set TTYs to be world- writable. Local attackers may be able to write arbitrary messages to logged-in users, including terminal escape sequences. Reported by Nikolay Edigaryev. * sshd(8): Portable OpenSSH only: Fixed a privilege separation weakness related to PAM support. Attackers who could successfully compromise the pre-authentication process for remote code execution and who had valid credentials on the host could impersonate other users. Reported by Moritz Jodeit. * sshd(8): Portable OpenSSH only: Fixed a use-after-free bug related to PAM support that was reachable by attackers who could compromise the pre-authentication process for remote code execution. Also reported by Moritz Jodeit. * sshd(8): fix circumvention of MaxAuthTries using keyboard- interactive authentication. By specifying a long, repeating keyboard-interactive "devices" string, an attacker could request the same authentication method be tried thousands of times in a single pass. The LoginGraceTime timeout in sshd(8) and any authentication failure delays implemented by the authentication mechanism itself were still applied. Found by Kingcope. Potentially-incompatible Changes -------------------------------- * Support for the legacy SSH version 1 protocol is disabled by default at compile time. * Support for the 1024-bit diffie-hellman-group1-sha1 key exchange is disabled by default at run-time. It may be re-enabled using the instructions at http://www.openssh.com/legacy.html * Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled by default at run-time. These may be re-enabled using the instructions at http://www.openssh.com/legacy.html * Support for the legacy v00 cert format has been removed. * The default for the sshd_config(5) PermitRootLogin option has changed from "yes" to "prohibit-password". * PermitRootLogin=without-password/prohibit-password now bans all interactive authentication methods, allowing only public-key, hostbased and GSSAPI authentication (previously it permitted keyboard-interactive and password-less authentication if those were enabled). New Features ------------ * ssh_config(5): add PubkeyAcceptedKeyTypes option to control which public key types are available for user authentication. * sshd_config(5): add HostKeyAlgorithms option to control which public key types are offered for host authentications. * ssh(1), sshd(8): extend Ciphers, MACs, KexAlgorithms, HostKeyAlgorithms, PubkeyAcceptedKeyTypes and HostbasedKeyTypes options to allow appending to the default set of algorithms instead of replacing it. Options may now be prefixed with a '+' to append to the default, e.g. "HostKeyAlgorithms=+ssh-dss". * sshd_config(5): PermitRootLogin now accepts an argument of 'prohibit-password' as a less-ambiguous synonym of 'without- password'. Bugfixes -------- * ssh(1), sshd(8): add compatability workarounds for Cisco and more PuTTY versions. bz#2424 * Fix some omissions and errors in the PROTOCOL and PROTOCOL.mux documentation relating to Unix domain socket forwarding; bz#2421 bz#2422 * ssh(1): Improve the ssh(1) manual page to include a better description of Unix domain socket forwarding; bz#2423 * ssh(1), ssh-agent(1): skip uninitialised PKCS#11 slots, fixing failures to load keys when they are present. bz#2427 * ssh(1), ssh-agent(1): do not ignore PKCS#11 hosted keys that wth empty CKA_ID; bz#2429 * sshd(8): clarify documentation for UseDNS option; bz#2045 Portable OpenSSH ---------------- * Check realpath(3) behaviour matches what sftp-server requires and use a replacement if necessary. Checksums: ========== - SHA1 (openssh-7.0.tar.gz) = a19ff0bad2a67348b1d01a38a9580236120b7099 - SHA256 (openssh-7.0.tar.gz) = 4F6HV/ZqT465f3sMB2vIkXO+wrYtL5hnqzAymfbZ1Jk= - SHA1 (openssh-7.0p1.tar.gz) = d8337c9eab91d360d104f6dd805f8b32089c063c - SHA256 (openssh-7.0p1.tar.gz) = /VkySToZ9MgRU9gS7k4EK0m707dZqz2TRKvswrwUheU= 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.
Posted Aug 11, 2015 14:11 UTC (Tue)
by mattdm (subscriber, #18)
[Link]
Posted Aug 11, 2015 14:30 UTC (Tue)
by Otus (subscriber, #67685)
[Link] (4 responses)
Wow, long past time to refuse 768 bit keys, those could demonstrably be factored six years ago.
I don't think even 1024 should really be considered secure any more either: http://crypto.stackexchange.com/a/1982/13625
Posted Aug 12, 2015 3:34 UTC (Wed)
by wahern (subscriber, #37304)
[Link] (3 responses)
But today it's no longer considered poor practice to generate prime groups dynamically. Still, generation of safe primes can take an appreciable amount of time even on modern hardware. Compare the running time of
$ openssl dhparam 1024
to
$ openssl genrsa 1024
(You may have to run the former multiple times if you, per chance, found one more quickly than usual.)
Generating the parameters dynamically causes headaches because of the possibly very long initial startup time and general logistical issues of doing it in-process. Most software on both the server and client side just doesn't know how to dynamically generate DH groups, even for ephemeral DH. This is especially true for embedded and appliance systems. This is why over the years there have been security issues with compromised DH parameters, such as when software projects or vendors generated parameters on systems with broken a PRNG, effecting everybody downstream.
But they all usually allow you to specify your own at startup. If you can't switch to ECDH, there's nothing wrong with generating your own random 1024-bit DH parameters. I seriously doubt the NSA will expend the same effort to crack a key used by one person the same as one shared by millions of people. Of course, 2048-bit would be even better. 1024-bit has stuck around for so long because in the 2000s there was still plenty of software which only worked with key sizes <= 1024 bits. But I can't imagine a randomly generated 1024-bit DH prime group being the weakest link in a targeted attack. Most people don't even have a hardware RNG. (It's a real shame Soekris doesn't provide their crypto accelerator in mini PCI express form; it's been useless for accelerating anything for years, but it sported the cheapest and most widely supported hardware RNG.)
With ECDH protocols you _must_ use shared curves (equivalent to shared prime groups for DH). You can't generate random ones, for various technical and functional reasons. So notwithstanding the greater strength of ECC, it also makes users easier targets in this respect. Which is perhaps why some people are very suspicious about the NIST-standardized curves.
Posted Aug 12, 2015 7:23 UTC (Wed)
by Otus (subscriber, #67685)
[Link]
I still think it's easier to just use a well known 2048-bit group (group 14), and that protects you from both targeted and untargeted attacks.
> So notwithstanding the greater strength of ECC, it also makes users easier targets in this respect.
But the solution is easy: just use a larger curve. A factor of 2^x in curve size is ~equivalent to having 2^(x/2) unique user defined curves instead. If 160-bit ECC is roughly equivalent to 1024-bit DH, you can step up to 256-bit ECC and be more secure than with a realistic amount of different curves. That's faster, with a good implementation, and has way smaller keys and messages.
Yes, you need to trust the curve, but there are a bunch of curves from independent parties now.
Posted Aug 13, 2015 9:39 UTC (Thu)
by jwilk (subscriber, #63328)
[Link] (1 responses)
They did. In fact, there are still 1024-bit RSA keys in the Mozilla CA store.
Posted Aug 24, 2015 12:14 UTC (Mon)
by gerv (guest, #3376)
[Link]
Gerv
Posted Aug 11, 2015 15:20 UTC (Tue)
by stqn (guest, #103999)
[Link] (8 responses)
Sshfs is very easy to setup and use, unlike nfs or samba... So I hope they reconsider the deletion of weaker algorithms.
It is my understanding that the new Raspberry Pi 2 is also relatively slow for encryption, so it is not only "old" computers that would be affected.
Posted Aug 11, 2015 15:32 UTC (Tue)
by mordocai (guest, #71668)
[Link]
Posted Aug 11, 2015 16:25 UTC (Tue)
by bgmarete (guest, #47484)
[Link]
Posted Aug 11, 2015 16:31 UTC (Tue)
by ibukanov (subscriber, #3942)
[Link]
Intel started to put AES instructions into Atoms since Q3 2013. If you have one of those, then aes128-gcm@openssh.com should be the fastest cipher.
Posted Aug 11, 2015 16:43 UTC (Tue)
by jtaylor (subscriber, #91739)
[Link] (2 responses)
Requiring some minor extra effort for niche use cases is in my opinion preferable than risking everyone else due to the possibility of misconfiguration or higher attack surface.
Posted Aug 11, 2015 19:56 UTC (Tue)
by stqn (guest, #103999)
[Link] (1 responses)
Posted Aug 13, 2015 0:18 UTC (Thu)
by malor (guest, #2973)
[Link]
The person at ImperialViolet benched an ARM7 CPU at about 90Mbyte/sec. Even a Pi 1 would probably be able to do half that. A Pi 2 would probably be loping at the 12.5Mbyte maximum data rate the platform can handle.
Posted Aug 11, 2015 19:01 UTC (Tue)
by jhoblitt (subscriber, #77733)
[Link] (1 responses)
http://www.psc.edu/index.php/hpn-ssh
My recollection, which may be faulty, is that is that the "none" cipher didn't make much of a difference below a few 100 mbit/s.
Posted Aug 11, 2015 19:18 UTC (Tue)
by jhoblitt (subscriber, #77733)
[Link]
Posted Aug 12, 2015 6:35 UTC (Wed)
by arekm (guest, #4846)
[Link] (1 responses)
Too bad that even explictly telling ssh client to use specific key doesn't work (without PubkeyAcceptedKeyTypes matching) like:
:-/
Posted Aug 12, 2015 15:40 UTC (Wed)
by nix (subscriber, #2304)
[Link]
is what you want.
If it was just a -i away, the algorithm wouldn't be disabled in any sense that I can see.
Posted Aug 12, 2015 11:45 UTC (Wed)
by glen (guest, #81012)
[Link] (2 responses)
Posted Aug 12, 2015 15:40 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Aug 13, 2015 0:32 UTC (Thu)
by malor (guest, #2973)
[Link]
ssh-keygen -t rsa -b 4096 -o
(the -o tells it to encrypt the file with a newer, stronger algorithm, making it harder to bruteforce the passphrase.)
The Curve25519 keys are about equivalent to 3072-bit RSA keys, and can be generated like this:
ssh-keygen -t ed25519
The resulting keys are quite short, only 32 bytes, and they generate almost instantly. There are no other options: all ed25519 keys are 256-bit, and all are stored with the better encryption.
If you want to force your ssh servers to use Curve25519 encryption only, you can do so with these lines:
Ciphers chacha20-poly1305@openssh.com
This explicitly turns off all other encryption. I'm not sure the MAC line actually does anything: someone commented that there's a MAC built into Curve25519 encryption already. So that line may be superfluous.
You can put the same lines in ssh_config, as well, if you want to force those options on all outgoing connections.
This is a very fast algorithm, and will run very well even on weak CPUs. On a modern Intel processor with the AES New Instructions, hardware-accelerated AES is faster than Curve25519, which might be an issue if you're driving extreme bandwidth. Most processors with AESNI should still be able to saturate a gigabit with Curve25519, but an unusually weak CPU or unusually large bandwidth demands might make hardware-accelerated AES more attractive.
Perhaps foolishly, the biggest reason I trust Curve25519 was because the NIST had nothing whatsoever to do with it: after the DUAL_EC random number generator debacle (it was deliberately compromised by the NSA, who then bribed the RSA company to make it their default RNG), I'd rather use encryption standards that the American government has nothing whatsoever to do with.
OpenSSH 7.0
OpenSSH 7.0
OpenSSH 7.0
OpenSSH 7.0
OpenSSH 7.0
OpenSSH 7.0
OpenSSH 7.0
OpenSSH 7.0
OpenSSH 7.0
OpenSSH 7.0
OpenSSH 7.0
So the solution is simple: just use an older version of ssh or don't update whatever you have now.
OpenSSH 7.0
OpenSSH 7.0
OpenSSH 7.0
OpenSSH 7.0
OpenSSH 7.0
ssh -i .ssh/my_dsa_key host
OpenSSH 7.0
generating keys
generating keys
generating keys
MACs hmac-sha2-512-etm@openssh.com
KexAlgorithms curve25519-sha256@libssh.org