102 ms·

OpenSSH 8.6 Released

86 points by eplanit 6y ago

johnklos 6y 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 6y ago
  Hell, my company uses Azure repos, and they're still stuck on ssh-rsa keys: https://developercommunity.visualstudio.com/content/idea/365980/support-non-rsa-keys-for-ssh-authentication.html https://developercommunity.visualstudio.com/content/idea/365...
  - b0afc375b5 6y ago
    Also aws: https://forums.aws.amazon.com/thread.jspa?threadID=250753 https://forums.aws.amazon.com/thread.jspa?threadID=250753
    - gspr 6y ago
      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).
      - b0afc375b5 6y ago
        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.
  - hannob 6y 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.)
    - lxgr 6y ago
      > 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?
      - gruez 6y ago
        It's used by the client to authenticate the server, since openssh shows you the key fingerprint (hash) upon connecting, not the raw key.
        lxgr 6y ago
        My client displays SHA256 fingerprints even for RSA servers. `.known_hosts` seems to store the full key anyway, not just a fingerprint.
RcouF1uZ4gsC 6y 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 6y 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 6y 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.)
    - vlovich123 6y ago
      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?
      - er4hn 6y ago
        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.
pentestercrab 6y 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 6y 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://github.com/golang/go/issues/37278 https://go-review.googlesource.com/c/crypto/+/220037/ https://go-review.googlesource.com/c/crypto/+/220037/
- papaf 6y ago
  Thanks for your hard work on this bug -- I got bitten by it and I would really like to see the fix released.
- gruez 6y 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.
deleted 6y ago
[deleted]
elric 6y 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?

86 points by eplanit 6y 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 6y ago
Hell, my company uses Azure repos, and they're still stuck on ssh-rsa keys: https://developercommunity.visualstudio.com/content/idea/365980/support-non-rsa-keys-for-ssh-authentication.html https://developercommunity.visualstudio.com/content/idea/365...
- b0afc375b5 6y ago
  Also aws: https://forums.aws.amazon.com/thread.jspa?threadID=250753 https://forums.aws.amazon.com/thread.jspa?threadID=250753
  - gspr 6y ago
    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).
    - b0afc375b5 6y ago
      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.
- hannob 6y 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.)
  - lxgr 6y ago
    > 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?
    - gruez 6y ago
      It's used by the client to authenticate the server, since openssh shows you the key fingerprint (hash) upon connecting, not the raw key.
      - lxgr 6y ago
        My client displays SHA256 fingerprints even for RSA servers. `.known_hosts` seems to store the full key anyway, not just a fingerprint.

RcouF1uZ4gsC 6y 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 6y 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 6y 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.)
  - vlovich123 6y ago
    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?
    - er4hn 6y ago
      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.

pentestercrab 6y 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 6y 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://github.com/golang/go/issues/37278 https://go-review.googlesource.com/c/crypto/+/220037/ https://go-review.googlesource.com/c/crypto/+/220037/

papaf 6y ago
Thanks for your hard work on this bug -- I got bitten by it and I would really like to see the fix released.
gruez 6y 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.

deleted 6y ago

[deleted]

elric 6y 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?