OpenSSH 8.6 Released

by eplanit • 5 years ago

86 22 5 years ago

johnklos• 5 years ago

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

minedwiz• 5 years ago

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

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

b0afc375b52• 5 years ago

Also aws:

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

hannob• 5 years ago

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.)

RcouF1uZ4gsC• 5 years ago

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).

encryptluks2• 5 years ago

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.

loeg• 5 years ago

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.)

pentestercrab• 5 years ago

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.

hansnielsen• 5 years ago

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/

papaf• 5 years ago

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

gruez2• 5 years ago

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.

elric• 5 years ago

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?

OpenSSH 8.6 Released

Related Stories