OpenSSH To Deprecate SHA-1 Logins Due To Security Risk (zdnet.com) 39
OpenSSH, the most popular utility for connecting to and managing remote servers, has announced today plans to drop support for its SHA-1 authentication scheme. From a report: The OpenSSH team cited security concerns with the SHA-1 hashing algorithm, currently considered insecure. The algorithm was broken in a practical, real-world attack in February 2017, when Google cryptographers disclosed SHAttered, a technique that could make two different files appear as they had the same SHA-1 file signature. At the time, creating an SHA-1 collision was considered computationally expensive, and Google experts thought SHA-1 could still be used in practice for at least half a decade until the cost would go down. However, subsequent research released in May 2019 and in January 2020, detailed an updated methodology to cut down the cost of an SHA-1 chosen-prefix collision attack to under $110,000 and under $50,000, respectively.
No, SHA-1 is not "insecure" (Score:5, Interesting)
Can we please get minimal factual accuracy?
SHA-1 is insecure when collision resistance is a factor and when both (!) things that generate the collision are chosen by the attacker. That is a very specific situation. SHA-1 remains perfectly secure in many other applications.
As far as I can see, the situation for OpenSSH is that an attacker would need to create a second key with the same SHA-1 hash as an already existing one. That is still infeasible to the best of my knowledge and can reasonably be expected to be several orders of magnitude more difficult. Hence I will just re-enable this feature when it is not the default anymore.
hmac (Score:2)
As I understand it, hmac remains secure [wikipedia.org] even when the underlying hash is subject to collisions.
Is OpenSSH removing sha-1 in a different context, and leaving hmac-sha1?
Re:hmac (Score:5, Informative)
From the actual release notes [openssh.com] and not the zdnet article (you suck M'Smash):
Future deprecation notice
It is now possible[1] to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release.
[...snip...]
To check whether a server is using the weak ssh-rsa public key algorithm, for host authentication, try to connect to it after removing the ssh-rsa algorithm from ssh(1)'s allowed list:
ssh -oHostKeyAlgorithms=-ssh-rsa user@host
If the host key verification fails and no other supported host key types are available, the server software on that host should be upgraded.
Re: (Score:2)
Yes, I have seen this. It is uninformative to say the least.
Re: hmac (Score:1)
Re: (Score:2)
The ZDNet article is gibberish in its understanding of how RSA and SSH are used in SSH so it's a bit hard to extrapolate anything from it, but ignoring their description the attack being referenced is an offline chosen-prefix attack on long-term signed data while what SSH uses to auth is ephemeral data that would need to be attacked in real time. Completely different attack.
The OpenSSH move then is just PR to appease people who understand as little about it as ZDNet. "SHA1 bad -> we make SHA-1 go away
Re: (Score:2)
I'm not meaning to argue against your point, but - is there any particular reason you want/need continued SHA-1 support?
Our group finished switching over all our keys to Ed25519 a year or so ago.
Re: (Score:3)
The typical answer to this is "old hardware that's still in service in an otherwise secure environment but doesn't support more modern crypto".
People in such situations really hate it when developers shut off their access without recourse.
Re: (Score:2)
That is not the situation. The old version can just be re-enabled. It is just not enabled by default. That is, I think, a reasonable step by the OpenSSH team as it will lead to slowly phasing out of the old scheme. At this time it seems to remain secure, but one-sided SHA-1 collisions may or may not become feasible in the next few years.
What I object to is to call SHA-1 "insecure" without qualification and, worse, in a scenario where it is not (yet) insecure.
Re: (Score:1)
That's too invasive. If I upgrade sshd without making any changes to sshd_config, the server suddenly become inaccessible to users with older keys or older ssh-clients.
Right now I'm facing a similar problem with an account, for which I have only a DSS-key — it is no longer acceptable after the University upgraded the server's OS. An e-mail requesting re-enabling of DSS (which should not have been deprecated either [stackexchange.com]) remains unanswered for three days...
It is a comp
Re: (Score:2)
That's too invasive.
Depending on the situation, yes, it can be. But for other situations there is a recourse that does not have you patching the sources.
Also, as far as I understand this, the old ones will continue to work on server-side, they will just not be generated that way anymore.
Hence any parameters to set would be at the client. I may be wrong about this.
If I upgrade sshd without making any changes to sshd_config, the server suddenly become inaccessible to users with older keys or older ssh-clients.
Right now I'm facing a similar problem with an account, for which I have only a DSS-key — it is no longer acceptable after the University upgraded the server's OS. An e-mail requesting re-enabling of DSS (which should not have been deprecated either [stackexchange.com]) remains unanswered for three days...
3 days? I raise you by 12 days. Of course, that was just the access being cut that I need to support a critical production systems at a customer where 3000 people dep
Re: (Score:2)
3 days? I raise you by 12 days.
Currently at 24 days for a replacement for my five-year old laptop, although it was approved 22 days ago. The (relatively new) SSD is getting flaky and I'm getting increasingly common "failure to find boot device" messages on startup. Sometimes our EIT folks are on top of things, and sometimes they have to be "encouraged" by senior management.
Re: (Score:2)
Why would an upgrade touch your config? That's completely nonstandard behavior without some sort of prompting.
Re: (Score:2)
Old config:
# leave commented to use defaults
# HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
This will stop working if the defaults change.
FWIW, I got sort of locked out from a server at work last year, when a server upgrade came with a new default minimum key length, which was larger than the key I'd been using for 10 years.
The main problem is: OpenSSH is absolutely atrocious if you need to figure out the cause of authentication failures. It won't give you a he
Re: (Score:2)
The main problem is: OpenSSH is absolutely atrocious if you need to figure out the cause of authentication failures.
True, though that's a common design of security software. I'm not a fan, though I understand it. Security is a trade-off, and if my security depends on bad guys lacking knowledge than I've probably already lost.
If you can run sshd with "-d" temporarily, you'll get lots of useful diagnostic messages in the daemon's stderr. Add more -d's for more messages.
Re: (Score:2)
Another major problem is the time outs don't work when the ssh rejects an old key, it just sits there forever waiting for different things with the assumption that a human is there to type at it.
That is a real problem for hardware that is using it to connect to remote systems and it often involves a truck roll to fix. A default timeout of 60 seconds for any prompt would fix that.
A nice error log message saying "client XYZ connected using a soon to be deprecated cipher foo, -o enablefoo will be required afte
Re: (Score:1)
That's too invasive.
Security is about tradeoffs. I'm happy if the openssh devs change a default which makes most people slightly more secure, even if it makes a few people slightly inconvenienced. Even if SHA-1 is "secure enough" now, attacks only get cheaper.
If anything is going to break, I want it to break during the next normal upgrade cycle, not when SHA-1 is completely broken and the PHBs are panicing. You should be able to handle ssh breaking; it's not the only way into your systems, right? If so, I see the problem a
Re: (Score:2)
It ought to wind up being just users with old SSH clients. And it could be prevented by following this change and making sure to update clients before updating servers.
Older RSA keys of at least 2048 bits ought to be able to function fine with an updated protocol. There is no SHA1 component to a user's SSH key... Its a RSA public key pair.. that includes a Public Key, and a Private Key. The entire public key should be on the server, not a hash of the public key.
If these are in the context wh
Re: (Score:2)
--Wouldn't a jump server fit the bill at that point? Sure, it might add some latency but if you really need to keep the functionality, it's either that or edit the source code
Re: (Score:2)
Not really, except that I see no point investing the work. Things work as they are now and as far as I can see remain secure. Sure, next time I have a valid reason to change those keys, I will probably go to the SHA512 variant or the Ed25519 one (the only ECC curve I halfway trust), but at the moment I see no reason for action.
Re: (Score:2)
There are still many things that require an rsa key and will reject any newer type of key, aws and azure spring to mind as i recently had to create an rsa key for these as they wouldn't accept my ed25519 key.
Re: (Score:1)
Our group finished switching over all our keys to Ed25519 a year or so ago.
Just when I give up on slashdot, you go and post something useful.
Re: (Score:3)
Re: (Score:2)
I agree to that. It is a prudent step to slowly phase out SSH-1 for this usage. What I disagree with it calling it "insecure" without qualification and, more so, in a situation where that is not (yet) true.
Re: (Score:2)
Undeprecate DSS too (Score:1)
The DSS-keys are already declared "deprecated" for no good reason, as explained here [stackexchange.com].
OpenSSH developers need to get more responsible than this — their software is in every Unix computer nowadays, they ought to avoid sudden moves like this without very good reasons.
Just makes the paranoid side of me suspect, they are trying to corral us all towards use of key-formats and protocols NSA has secretly cracked :)
Re: (Score:2)
The DSS-keys are already declared "deprecated" for no good reason, as explained here [stackexchange.com].
OpenSSH developers need to get more responsible than this — their software is in every Unix computer nowadays, they ought to avoid sudden moves like this without very good reasons.
Just makes the paranoid side of me suspect, they are trying to corral us all towards use of key-formats and protocols NSA has secretly cracked :)
Well, DSS is a potential problem. That justifies not making it the default, but deprecating it may be a bit much.
As to backdoored crypto, I do not trust ECC. Maybe I can live with the DJB curve, but given a choice I will stay with RSA. The constant over-hyping of the (mostly imaginary) threat that quantum computing supposedly poses to RSA has made me highly suspicious.
Re: (Score:2)
The nice thing is that you can just re-enable them if necessary. There are NULL-ciphers you can enable in OpenSSH too, I personally think the defaults should be paranoid.
Re: (Score:2)
False. SHA-1 is so broken you can use it as lossless compression.
If only it were permanently removed... (Score:1)
What? (Score:2)
This wasn't done already like years ago? Were they fucking crazy? Why did they let this slide for so long? We've known SHA-1 was crap for at least a decade, maybe even 15 years if I think about it.
Re: (Score:2)
This wasn't done already like years ago? Were they fucking crazy? Why did they let this slide for so long? We've known SHA-1 was crap for at least a decade, maybe even 15 years if I think about it.
They switched the defaults to generate stronger hashes at least 10 year ago. Note as the first comment mentions to attack ssh, a collision is not enough, you need to generate a private key with a public key that collides.
Stop deprecating crypto! (Score:2)
For developers in ivory towers, disabling cryptographic algorithms because "attacks" is their reason to live.
In the trenches you have the systems administrators that maintain systems and actually have to deal with these incompatibilities. Because of "Lets disable SSL" in java, I need to keep Windows 7 systems around with Java 1.6 installed and I cannot patch them or I lose contact with some systems.
Not everything can be upgraded or updated to the latest crypto.
And me needing to spend $100,000 on new equipme
Re: (Score:2)
The problem with the "hard shell, gooey inside" security method is that if there is ever a hole in the hard shell, you can lose everything. More, you may not even know it since if you don't keep internal systems secure from each other, an attacker will probably never be detected.
Also, there is always a hole. Especially when the admin says "no way there can be a hole, I'm too good." I'm not that good, but I was good enough to know there was a hole somewhere.
Just my experience from a previous life of secur
Re: (Score:1)
> The problem with the "hard shell, gooey inside" security method is that if there is ever a hole in the hard shell, you can lose everything.
Any company that's big enough is like this, you just have to know where the "goo" is. It's just too damn hard and too damn expensive for it to be any other way.
Re: (Score:2)
Amen to that. Although I think, at the moment, they're just disabling it by default so it can be reenabled.
It's when stuff gets removed completely that it becomes a problem.
I have virtual machines who are carefully firewalled from getting any updates at all so that I keep old working versions of software. ipmi is a particular issue - needing old versions of browsers, old versions of java (many of which can be hard to find)
It gets worse because many of these systems are never accessed normally - but when the