OpenSSH 7.0 Released

An anonymous reader writes: Today the OpenSSH project maintainers announced the release of version 7.0. This release is focusing on deprecating weak and unsafe cryptographic methods, though some of the work won't be complete until 7.1. This release removes support for the following: the legacy SSH v1 protocol, the 1024-bit diffie-hellman-group1-sha1 key exchange, ssh-dss, ssh-dss-cert-* host and user keys, and legacy v00 cert format. There were also several bug fixes, security tweaks, and new features. In the next release, they plan to retire more legacy cryptography. This includes refusing RSA keys smaller than 1024 bits, disabling MD5-based HMAC algorithms, and disabling these ciphers: blowfish-cbc, cast128-cbc, all arcfour variants and the rijndael-cbc aliases for AES.

Comments

NSA responds

[Anonymous Coward]

> This release is focusing on deprecating weak and unsafe cryptographic methods,

awwwwwwwwwwwwwwww!!!!!

> though some of the work won't be complete until 7.1.

well I guess that is okay then...

> This release removes support for the following: In the next release, they plan to retire more legacy cryptography. This includes refusing RSA keys smaller than 1024 bits,

LOL! Well, If it makes u feel safer! hahahahaha! http://gizmodo.com/nsa-paid-se...

> disabling these ciphers: blowfish-cbc,

Damn you Bruce Schneier! ''Please take a moment to read Authenticated Encryption and understand why you should prefer to use CCM or EAX over other modes, such as CBC or CTR'' http://www.cryptopp.com/wiki/A...

Re:NSA responds

[jonwil]

RSA the algorithm isn't insecure if you use a big enough key. RSA the company may have released some weak products (at the request of the NSA or otherwise) but nothing they did affects the security of RSA the algorithm or the implementation of RSA that is in OpenSSH.

Re:NSA responds

[Anonymous Coward]

Was a joke, man. Y so serious?

Re:NSA responds

[petermgreen]

The problem is "big enough key", how big is big enough? best estimate seems to be that 4096 bit is fine for the forseeable future but noone really knows because noone can predict how integer factorisation algorithms will progress.

When RSA was developed it was thought that 1024 bit keys would be secure essentially forever. Unfortunately the combination of advancements in integer factorisation techniques and advancements in computing power have brought factoring a 1024 bit key into the range of computationally feasible (though very expensive). Furthermore that is based on what is publically known, it's not beyond the realms of possibility that the spooks know techiquest that the public doesn't.

Unfortunately 1024 bit keys were the standard size for years and so are extremely common. Getting rid of them is going to involve quite a bit of pain. It's telling that openssh only plan to refuse keys smaller than 1024 bit, not keys that are exactly 1024 bit.

Re:NSA responds

[Anonymous Coward]

The main problem with RSA and the future is that as the key gets larger, the time to setup a connection increases exponentially. If you double the key-size, the time needed to verify/sign goes up by 3x-5x. That's not sustainable and using 8192 or 16384 bit keys will require way too much CPU power compared to alternatives like EC. EC can do the same job with less CPU power and with a smaller key size while providing the same "strength".

Re:NSA responds

[Anonymous Coward]

Nobody ever thought 1024-bit RSA would last forever. Commercial Certificate Authorities were using 4098-bit keys for signing in the 1990s!

And don't confuse Diffie-Hellman keys with RSA. It's basically known that the NSA has cracked 768-bit Diffie-Hellman prime groups, and possibly 1024-bit. But the difference is that almost all modern software uses shared prime groups (for various historical reasons). This means if you precompute factorization tables for a 1024-bit DH prime group, you can snoop on millions of people using that prime group. Your secret key in DH is a simple random integer. Whereas for RSA you use two large primes, one of which is unique and secret.

So while the NSA could break 1024-bit RSA, it's not nearly as useful as breaking 1024-bit DH. In the former they only gain access to a single key channel; in the latter they gain access to the communications of the millions, perhaps billions, of people using that prime. And it's not like cracking a 1024-bit prime is cheap; they have to dedicate insane amounts of resources to it.

CAs have never used 1024-bit RSA because they knew that they were prime targets (pun intended).

Re:NSA responds

[sjames]

advancements in computing power have brought factoring a 1024 bit key into the range of computationally feasible (though very expensive).

And there's your answer, even those too weak keys are still too expensive to routinely crack. More sensitive logins should have been using 4096 all along. Start updating now.

Re:NSA responds

[sjames]

Currently, the login time for a 4096 bit key is practically lost in the noise. I doubt very much that 3x-5x is at all prohibitive.

Given the NSA's research on EC, that may or may not work out better.

Re:NSA responds

[Gallomimia]

Prove it.

Use lambda calculus.

I'll wait.

Re: NSA responds

[Anonymous Coward]

4096-bit is quick enough, yes, but try a 8192-bit key, and you'll quickly (or not so quickly) see why increasing the key size isn't a feasible future-proofing method.

none cipher?

[Anonymous Coward]

I hope they add a "none" cipher.

I use ssh for X11 forwarding and encryption really slows it down. Currently I'm using arcfour because it's the fastest one. But TFS says that's going away in 7.1. Guess it's time to look for a patch.

No, I don't want encryption between these machines. I would run "xhost +", but setting $DISPLAY after a script remotely logs in is ugly. " ssh -Y" makes it so much easier, cleaner, and more likely to be correct.

Re:none cipher?

[fnj]

I've been there, so I know the feeling. It's frustrating to be treated like children incapable of deciding what level of security YOU need, including none. But jeeze, in 2015 you must be running unbelievably shitty old hardware to even notice any slowdown any more with the best ciphers.

Re:none cipher?

[bill_mcgonigle]

Are you running old hardware? I've switched over to "-c aes128-ctr" for the best speed/security/compatibility compromise, but I have hardware AES. I get about a gigabit between vm's.

ssh -c aes128-ctr -o Compression=no hostname cat /dev/zero |pv | cat > /dev/null

on Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz

Re:none cipher?

[hankwang]

in 2015 you must be running unbelievably shitty old hardware to even notice any slowdown any more with the best ciphers.

Does running rsync on an Android phone or a low-end NAS qualify? I prefer to keep my backups local rather than in the cloud. I've said it before: The weaknesses in RC4/arcfour are all about leaking key information in the first 256 or maybe 512 bytes of cipher stream, because that's how long it takes to scramble the internal state. SSH always discards the first 1.5 kiB, so it's not vulnerable to this kind of attack. Why deprecate it?

Re: none cipher?

[ModernGeek]

Yeah, like when I want to create a kiosk from scratch using linux and want to have it autologin as a user and start x.

Asking on forums just leads to one being berrated and told that it is insecure to have a machine where someone is logged in without producing credentials. Why is it not a valid security model, to have a user called "public"? Especially whenever nothing mission critical is used on said machine?

Re: none cipher?

[Anonymous Coward]

You may be asking on the wrong forum, just use Google and you will get tons of results.
Every dm offers that i know of has an autologin setting.
If you don't have a dm you can configure init to spawn a shell on tty1 (it's trivial with old school /etc/inittab or a systemd unit ), the shell then starts x in *_profile. Maybe it's also possible to set startx as the login shell to avoid a fork, never tried that.
You should also have a look into PAM, it can be used to customize your security model.

Re:none cipher?

[Anonymous Coward]

Unless you have some ancient version without the cipher, using 'ssh -c chacha20-poly1305@openssh.com' should saturate gigabit ethernet on any recent hardware, even without crypto extensions. Even my ancient 1.8GHz Athlon64 can sink about 50MB/s over the network, and that is with a C implementation. With optimized assembly primitives, chacha20-poly1305 is blindingly fast.

Re: none cipher?

[ModernGeek]

Yeah, the solution to get this done is easy, it's just sometimes hard to understand the elitism within some support communities when it comes to answering basic questions for scenarios that don't match the use most common use cases.

Re:none cipher?

[Anonymous Coward]

Turn on compression in the ssh config, or usesome other tool that isn't specifically designed to encrypt data like telnet or something.

Re:none cipher?

[Ed Avis]

I patched 'none' encryption into openssh many years ago: http://membled.com/work/patche...

Re:none cipher?

[perryizgr8]

Isn't it 'ssh -X' instead of 'ssh -Y'?

Re:none cipher?

[Anonymous Coward]

-Y disables the X11 SECURITY extensions.

Re:none cipher?

[Anonymous Coward]

Install openssh-hpn. It has supported a null symmetric cipher forever.

Sometimes you only need authentication, not privacy. I don't know what's with all the hater responses; it's often the case that you have a machine on a network that can't be snooped (any decent managed ethernet forwarding domain), but can be reached from the outside, so you want the convenience and security of ssh public key authentication, but you have no need for privacy. With 10G or 40G ethernet, even a fast cipher like Chacha20 can introduce intolerable slow-down or cpu overhead.

Re:none cipher?

[Anonymous Coward]

Or you can just use openssh-hpn, which has a null cipher, along with other high performance networking improvements, and is available in repos for many distros.

Re:none cipher?

[Bert64]

Such an option has been supported for a while, at least within the HPN patch...
Back when i used remote X11, it would automatically forward the DISPLAY parameter when logging in (over telnet in those days), ie it would take your display number (:0) and append it to the end of the host you logged in from.
You could also look into an x11 compression system like NX if bandwidth is lacking.

Re:none cipher?

[arglebargle_xiv]

I patched 'none' encryption into openssh many years ago

We assume the fruit basket and flowers arrived OK?

Love,
The NSA.

Re:none cipher?

[petermgreen]

http://www.openbsd.org/cgi-bin...

-X
        Enables X11 forwarding. This can also be specified on a per-host basis in a configuration file.
        X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the user's X authorization database) can access the local X11 display through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring.
        For this reason, X11 forwarding is subjected to X11 SECURITY extension restrictions by default. Please refer to the ssh -Y option and the ForwardX11Trusted directive in ssh_config(5) for more information.
-x
        Disables X11 forwarding.
-Y
        Enables trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls.

http://www.openbsd.org/cgi-bin...

ForwardX11Trusted
        If this option is set to “yes”, remote X11 clients will have full access to the original X11 display.
        If this option is set to “no”, remote X11 clients will be considered untrusted and prevented from stealing or tampering with data belonging to trusted X11 clients. Furthermore, the xauth(1) token used for the session will be set to expire after 20 minutes. Remote clients will be refused access after this time.

In summery it seems that -X is more secure than -Y but can break things in some cases.

Re:none cipher?

[snkhere]

Have you considered using ChaCha20? It is - supposedly - faster than RC4 ( https://security.stackexchange... ) and not broken ( http://www.rc4nomore.com/ ). Of course, please benchmark yourself.

Re: none cipher?

[Anonymous Coward]

If the network is so secure, why do you even need authentication? How can you do authentication properly without encryption? It sounds like your analysis of the situation is fundamentally flawed.

Re:none cipher?

[Anonymous Coward]

AES acceleration is part of even ARM processors. So no, a low-end NAS or Android phone do not qualify, at least not merely on that basis.
https://en.wikipedia.org/wiki/AES_instruction_set#Hardware_acceleration_in_other_architectures

Encryption still isn't free, but the performance difference is no nearly as large as most people imagine. On slower hardware it's more evident, but only because the overall transfer rate is already quite slow.

There's also nothing keeping you from running telnet and/or netcat to get data between boxes if you really don't want encryption.

Re:none cipher?

[tao]

You might still want to connect safely, then have the communication in clear text. When transferring say, 64GB of photos to your NAS, you might not care that much whether someone can eavesdrop on the transfer itself, but it'd suck to give away your password.

Though what with the typical "security" of consumer NAS devices, I guess there are enough security vulnerabilities to make cleartext passwords mostly irrelevant anyway.

Re:none cipher?

[Anonymous Coward]

I don't object to individual in special-use cases tweaking their SSH installations to support those particular uses, but clearly you can see why it's undesirable to allow a typical SSH installation to be configured that way. And since OpenSSH is open source it's pretty trivial to make whatever sort of patch you want for special uses.

You might also consider IPSec in AH mode, wherein packets are authenticated but not encrypted.

That being said, I'm unclear how "can't be snooped" and "needs encrypted auth" go together in the scenario you describe. If you're talking about "reachable from the outside" that definitely means "snoopable", and therefore generally worth encryption. And if you're talking about use exclusively in a domain that you consider secure enough to preclude encryption I don't understand why you'd want SSH instead of telnet or netcat, both of which are much lower overhead.

Re:none cipher?

[Anonymous Coward]

It'd have to be out-of-tree or something; having a built-in none cipher that could be used accidentally across the internet would be a very bad thing.

Re:none cipher?

[Ed Avis]

This was for running ssh on a 16MHz 386SX back in the day... it really was limited by encryption speed and not the buffer size issues which openssh-hpn fixes.

Re:none cipher?

[Warma]

An old NAS I have at home is only capable of transferring about one Mb/s through ssh (with modern linux machines). That is slow enough that transferring anything semi-large may take a day or so. Not unbearable, but still a bit too slow.

I have to admit that I haven't really looked into using alternative ciphers beyond the default one, but considering that that NAS is completely inside a LAN, having a 'none' cipher for occassional large transfers wouldn't hurt.

Re:none cipher?

[Anonymous Coward]

I hope they add a "none" cipher.

I use ssh for X11 forwarding and encryption really slows it down. Currently I'm using arcfour because it's the fastest one. But TFS says that's going away in 7.1. Guess it's time to look for a patch.

No, I don't want encryption between these machines. I would run "xhost +", but setting $DISPLAY after a script remotely logs in is ugly. " ssh -Y" makes it so much easier, cleaner, and more likely to be correct.

SSH_ARRAY=($SSH_CLIENT)
export DISPLAY=${SSH_ARRAY[0]}:0.0

And you got modded to +5?

Re:none cipher?

[Anonymous Coward]

I have to admit that I haven't really looked into using alternative ciphers beyond the default one, but considering that that NAS is completely inside a LAN, having a 'none' cipher for occassional large transfers wouldn't hurt.

Can you run rsyncd (on port 873) instead of tunnelling through SSH?

Re:none cipher?

[Anonymous Coward]

The problem is likely not the encryption, but the limitations of SSH. SSH performance is affected strongly by latency. Across a WAN with 20-30ms of latency, you will struggle to get more then 4-10Mbps. And higher latencies are worse. Even on the local network with 1ms latency, you will struggle to hit 100-200Mbps.

Unfortunately, OpenSSH, and the other vendors have not seen fit to merge in the "high speed" patches which fix a lot of these issues and allow SSH to use more of the pipe.

Re:none cipher?

[tlhIngan]

Does running rsync on an Android phone or a low-end NAS qualify? I prefer to keep my backups local rather than in the cloud. I've said it before: The weaknesses in RC4/arcfour are all about leaking key information in the first 256 or maybe 512 bytes of cipher stream, because that's how long it takes to scramble the internal state. SSH always discards the first 1.5 kiB, so it's not vulnerable to this kind of attack. Why deprecate it?

Android phones have their own encryption accelerators, so using AES would work juts fine.

A low end NAS with rsync? Can't rsync work without ssh on a local network? That would seem fastest. Or if NFS/SMB/CIFS is faster, use rsync locally through a remote mount so rsync just copies files locally and the kernel takes care of transferring over the network.

Re:none cipher?

[Anonymous Coward]

Use OpenVPN for that. OpenVPN has a "null" encryption cipher.

Re:none cipher?

[adolf]

There used to be a "none" cypher. It's been gone for a very long time. I never understood why it needed to go away: Sometimes, all you need/want is good authentication.

I used it eons ago on 486-ish hardware for remote X on an unswitched LAN. It worked great.

Re:none cipher?

[Uecker]

Sadly '-Y' is slow because RENDER is not available for untrusted clients. And '-X' does not offer more protection on most Linux systems because they usually default to trusted connections. It really a sad situation.

Re:none cipher?

[Bengie]

64KiB buffer. Divide by latency to get theoretical max throughput. 64KiB/0.1sec(100ms) = 614KiB/s. Yeah, pretty slow.

Re:none cipher?

[Anonymous Coward]

There is an unofficial patch set that adds the none cypher:

http://www.psc.edu/index.php/h...

Re:none cipher?

[ebvwfbw]

New command for you, xhost -
Now anyone can connect.

Might as well after all.

Watch out for old hardware

[thogard]

If you have old SSH1 only type devices (like old switches and routers), you might not be able to talk to them anymore after this update. You might want to keep a version of 6.6 around as ssh1 to talk to the old stuff that can't be upgraded to newer stuff.

Re:Watch out for old hardware

[darkain]

Sad but true, I keep legacy VMs laying around just to log into various client's legacy hardware for that once a year time they need some admin task taken. Looks like this will be added to the "legacy VM suite" I carry around.

Re:Watch out for old hardware

[Noryungi]

If you have old SSH1 only type devices (like old switches and routers), you might not be able to talk to them anymore after this update. You might want to keep a version of 6.6 around as ssh1 to talk to the old stuff that can't be upgraded to newer stuff.

OK, here is a hint for you: SSH v1 is a compile option.

Simply enter: ./configure --with-ssh1 ; make ; sudo make install and you will have the latest version of OpenSSH, with SSH v1 baked in.

Add a couple of options to your personal ~/.ssh/config (you do have a personal SSH config, right?) for these obsolete hosts, or simply add -1 to your ssh command and you are good to go.

There... That was not so hard now, was it?

Re:Watch out for old hardware

[Noryungi]

Really, an entire VM for a little old ssh? Is it really that hard for nowaday people to fetch an older version and configure/make/make install a single piece of software?

Yeah, well, I blame Ubuntu and Virtual Box. apt-get install openssh, oh fsck, I can't connect to my old router anymore... Damn you, OpenSSH devs! Damn you all to heck!!!

What? Compiling software? By hand? My dear man, you cannot be serious, I have better things to do with my time...

Re:Watch out for old hardware

[Anonymous Coward]

Maybe someone can create a PPA with old OpenSSH clients?

Re:Watch out for old hardware

[Anonymous Coward]

Like installing 6GB of VM? of course, your call.

Re:Watch out for old hardware

[Bert64]

Yeah while i agree with disabling old stuff by default especially in the server side implementation, the client should probably retain support for such things at least as a compile time option...

Re:Watch out for old hardware

[arglebargle_xiv]

Damn you, OpenSSH devs! Damn you all to heck!!!

Is heck the place people go who don't believe in gosh?

Re:Watch out for old hardware

[ncc74656]

Damn you, OpenSSH devs! Damn you all to heck!!!

I'm pretty sure Phil wouldn't have used "damn." The proper expression is "Darn you to heck!"

interesting

[bekid]

very interesting post

Re:Anyone

[Anonymous Coward]

Perhaps you should continue following the news for latest selfie sticks and shinier Apple gadgets?

Re:SSH is for cows.

[Anonymous Coward]

If only we could castrate the idiots injecting this excrement into every /. story we'd help the gene pool in a measurable fashion.

Version bump just for removing features?

[Anonymous Coward]

If they disable encryption entirely, will we see a mandatory upgrade to SSH 10 ?

Re: Version bump just for removing features?

[Anonymous Coward]

A version bump is entirely appropriate for dropping an entire protocol, plus a whole slew of other deprecated features. This is how "stable" software is developed and versioned.

Doing this in a point-release would cause significant uproar.

Re: Version bump just for removing features?

[Anonymous Coward]

I think OpenSSH has a similar 6 month release schedule that OpenBSD has.

blowfish-cbc !

[0xdeaddead]

i remembered when blowfish was the darling of OpenBSD.

Re:blowfish-cbc !

[kriston]

While blowfish-cbc is going away, which uses Cipher Block Chaining mode, I find it a little strange that OpenSSH does not offer the more secure blowfish-cfb, blowfish-ecb, or blowfish-ofb ciphers. They're certainly in OpenSSL, though blowfish in CTR mode is curiously not present in OpenSSL.

Frankly, why not offer CFB, ECB, OFB, and CTR modes for all ciphers that support it?

Re:blowfish-cbc !

[ebvwfbw]

Nothing wrong with cbc. It's still part of FIPS and if there were a problem, they'd surely remove it.
Someone put some BS out there that CBC isn't safe. It wasn't for about 3 months back in 2009. Then everyone fixed it.

Re:blowfish-cbc !

[kriston]

Blowfish is a solid cipher. I'm disappointed that I have to compile my own OpenSSH builds now with it re-enabled. What a silly joke this 7.0 release is going to be.

We seriously need to update Dropbear or some other SSH implementation to make this world better than it currently is.

Re:blowfish-cbc !

[ebvwfbw]

I remember implementing blowfish on an IBM Mainframe running mvs in assembler. I think that was in the early 1990s sometime. Before AES was out. I always thought it was a great cipher as well. However my cipher friends told me it's not that hard to crack. There are some flaws that make it vulnerable. Let me put it this way, don't bet your life on it. However for what I was using it for, it provided way more security than I needed.

My advice is to just use what's standard. Otherwise you'll spend a lot of time compiling, installing, and keeping it up to date. Believe me, it burns up time fast. If you don't keep it up to date, you can get burned if someone hacks you.

Re:blowfish-cbc !

[kriston]

Yup. EBC or CTR mode (which OpenSSH doesn't bother to enable) eliminate most of those security worries.

If you really feel this way...

[emil]

...then I encourage you to update and correct RFC 7525:

Implementations MUST NOT negotiate RC4 cipher suites.

Re:SSH is for cows.

[Anonymous Coward]

Or you could just reply to some of sexconker's posts, asking him to stop:

http://news.slashdot.org/comme...