OpenSSH 7.0 Released 75
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.
Re:NSA responds (Score:5, Informative)
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: (Score:3)
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 computationall
Re: (Score:2)
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: (Score:2)
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: (Score:1)
Use lambda calculus.
I'll wait.
none cipher? (Score:5, Interesting)
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: (Score:2)
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? (Score:5, Interesting)
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: (Score:1)
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 ge
Re: (Score:2)
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.
If you really feel this way... (Score:2)
...then I encourage you to update and correct RFC 7525 [ietf.org]:
Re: (Score:2)
Android phones have their own encryption accelerators, so using AES would wo
Re: none cipher? (Score:2)
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: (Score:2)
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? (Score:5, Interesting)
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.
on Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz
Re: (Score:1)
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: (Score:1)
Re: (Score:1)
Re: (Score:3)
I patched 'none' encryption into openssh many years ago
We assume the fruit basket and flowers arrived OK?
Love,
The NSA.
Re: (Score:2)
Isn't it 'ssh -X' instead of 'ssh -Y'?
Re: (Score:2)
http://www.openbsd.org/cgi-bin... [openbsd.org]
-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... [openbsd.org]
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: (Score:2)
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: (Score:1)
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 in
Re: (Score:2)
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: (Score:1)
Re: (Score:2)
Re: (Score:2)
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: (Score:1)
New command for you, xhost -
Now anyone can connect.
Might as well after all.
Watch out for old hardware (Score:3)
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: (Score:2)
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: (Score:2)
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 (Score:4, Funny)
Damn you, OpenSSH devs! Damn you all to heck!!!
Is heck the place people go who don't believe in gosh?
Re: (Score:2)
I'm pretty sure Phil wouldn't have used "damn." The proper expression is "Darn you to heck! [google.com]"
Re:Watch out for old hardware (Score:5, Informative)
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: (Score:2)
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...
blowfish-cbc ! (Score:3)
i remembered when blowfish was the darling of OpenBSD.
Re: (Score:2)
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: (Score:1)
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: (Score:2)
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: (Score:1)
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 ti
Re: (Score:2)
Yup. EBC or CTR mode (which OpenSSH doesn't bother to enable) eliminate most of those security worries.