OpenSSH 8.6 Released | Hacker News Reader

OpenSSH 8.6 Released

lwn.net

86 pointseplanit22 comments

Really looking forward to seeing ssh-rsa (i.e. RSA with SHA-1) behind us!

Unfortunately, implementation support for the new RSA with SHA-2 algorithms is still behind in some languages. I've had an open issue for Go's x/crypto/ssh since last February with an accepted proposal and working code, but I've struggled to get a review despite clear interest on the issue.

https://github.com/golang/go/issues/37278

https://go-review.googlesource.com/c/crypto/+/220037/

Thanks for your hard work on this bug -- I got bitten by it and I would really like to see the fix released.

>Really looking forward to seeing ssh-rsa (i.e. RSA with SHA-1) behind us!

Does it actually increase security? AFAIK the only relevant attack here is a preimage attack, and even md5 is still secure against it.

Security ========

* sshd(8): OpenSSH 8.5 introduced the LogVerbose keyword. When this option was enabled with a set of patterns that activated logging in code that runs in the low-privilege sandboxed sshd process, the log messages were constructed in such a way that printf(3) format strings could effectively be specified the low-privilege code.

   An attacker who had sucessfully exploited the low-privilege
   process could use this to escape OpenSSH's sandboxing and attack
   the high-privilege process. Exploitation of this weakness is
   highly unlikely in practice as the LogVerbose option is not
   enabled by default and is typically only used for debugging. No
   vulnerabilities in the low-privilege process are currently known
   to exist.

   Thanks to Ilja Van Sprundel for reporting this bug.

> The better alternatives include:

> ...

> The RFC8709 ssh-ed25519 signature algorithm. It has been supported in OpenSSH since release 6.5.

As an added bonus, in addition to increased security, because the ssh-edd25519 keys are so much shorter, it is much easier to use to cut and paste keys from the command line to a web page for ssh access (ie Github).

I remember working for a large Fortune 500 company and trying to get them to to let me use ed25519 instead of the RSA-1024 standard they had. Because they didn't know what ed25519 was and their security "expert" had told them RSA-1024 was the best, they said no way that they were already using the most secure algorithm.

Last time I checked (maybe 2019 or 2020), FIPS only permitted RSA for public-key cryptography. 1024-bit keys were no longer permitted, IIRC. If the company was involved in business with the USG (and many large companies are), they may have needed to comply with FIPS in some way (pure speculation). (Or the recommendation may have been on that basis, even if FIPS/USG was not involved in the ssh use.)

On the whole, does FIPS improve security or is it one of those compliance checkboxes that actually reduces security of those who know what they’re doing?

FIPS 140 provides a standard for assuring that a product has implemented their crypto correctly. It has its warts but overall it skews very close to otuer published sources of algorithms. I think the biggest differences lie in handling edge cases and key generation.

That said, receiving a FIPS certification is a huge effort in terms of time and money. I think it is tragic that neither NIST nor the NSA provide a already certified library you can integrate in. That would save enormous amounts of effort. Fun fact - lots of FIPS certifications are white labeled openssl with the latest set of FIPS requirements so I'm not even being that radical.

It's often a requirement for any Federal customers. It's a mixed bag in terms of security, since it does force you off of _very bad_ algorithms, but it doesn't always support the best algorithms.

FIPS does permit elliptic curves, but only a subset of the NIST ones. So ed25519 and the other djb algorithms are not allowed

there are ongoing changes to allow ed25519, eg, see: https://csrc.nist.gov/publications/detail/fips/186/5/draft

It's about time that we retire SHA-1 signature scheme. It'll be interesting to see how many older devices require updating.

Hell, my company uses Azure repos, and they're still stuck on ssh-rsa keys:

https://developercommunity.visualstudio.com/content/idea/365...

Also aws:

https://forums.aws.amazon.com/thread.jspa?threadID=250753

This isn't about wanting to replace RSA with Ed25519. The "ssh-rsa" method refers to RSA with SHA1 for hashing. It's the latter part that's the problem. The former is slightly inconvenient at worst (big keys).

Sure. But I was merely responding to the developercommunity forum post, which literally has the post body:

> Currently only RSA keys are supported. The documentation doesn’t mention this fact; further, no error message is given when an *Ed25519* key is added.

I wanted to express that this problem is not isolated to Azure.

There's really nothing wrong with RSA keys. This issue is about the combination of RSA with SHA1 hashes for signatures.

Using RSA with sha2-hashes is fine. (Yes, I know some people generally want to see RSA go away, but almost all more general issues with RSA have to do with encryption and not signatures, so SSH is pretty much unaffected.)

> This issue is about the combination of RSA with SHA1 hashes for signatures.

Is second preimage resistance actually relevant in the context of SSH authentication?

It's used by the client to authenticate the server, since openssh shows you the key fingerprint (hash) upon connecting, not the raw key.

My client displays SHA256 fingerprints even for RSA servers. `.known_hosts` seems to store the full key anyway, not just a fingerprint.

I'm a bit confused about the ssh-rsa ("with SHA-1") situation. Does this only refer to the way host keys are presented to connecting clients? Public (client) keys of the RSA type also start sith "ssh-rsa", but I don't understand where the SHA-1 hash comes into play there?

Reply on news.ycombinator.com