23 ms·

OpenSSH 8.2

118 points by beefhash 7y ago

beefhash 7y ago
Notably from the changelog: 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.
- RL_Quine 7y ago
  Just for fun, most users on Github have RSA keys exclusively. Did you know that your SSH keys are public on Github? https://github.com/taylorotwell.keys https://github.com/taylorotwell.keys https://github.com/alexcrichton.keys https://github.com/alexcrichton.keys https://github.com/andrew.keys https://github.com/andrew.keys https://github.com/egoist.keys https://github.com/egoist.keys https://github.com/fabpot.keys https://github.com/fabpot.keys Some of the most popular users even have DSS keys.
  - egyiedfyfrtjjf 7y ago
    As a RSA-user myself, because I learnt about ssh through the github setup guides: Will ssh-keygen generate a secure key if I don’t pass it any parameters?
    - RL_Quine 7y ago
      I haven't built the new version, but I assume it defaults to ed25519 now. You can otherwise make one with ssh-keygen -t ed25519.
      - techntoke 7y ago
        Last time I tried AWS doesn't support anything but RSA keys.
        RL_Quine 7y ago
        That’s right. Nothing stopping you having both though.
        zenexer 7y ago
        They don’t need to. Boot up a default AMI, change the key to whatever you want, then create your own custom AMI from that. Or you can use something like Cloud-Init.
        lawnchair_larry 7y ago
        This is good news, because AWS will finally be forced to get with the times. Their certificate manager is stuck on RSA too.
    - jlgaddis 7y ago
      It will generate a 2048-bit RSA keypair by default. It will be "a secure key" as long as you protect it with an appropriate passphrase.
      - gnufx 7y ago
        You need recent ssh-keygen's -o to make the passphprase effective (default for ed25519). That was covered here at some stage, but I don't have a reference.
  - zimmerfrei 7y ago
    You are conflating RSA (the algorithm) with "ssh-rsa" (the option of the SSH suite indicating authentication with RSA in combination with SHA-1). They deprecate the latter. Other options also based on RSA such as "rsa-sha2-256/512" are fine and will remain supported. In other words, the security problem is not with RSA per se. Having said that, I have not checked whether the people you list have RSA keys bound to SHA-1...
    - deleted 7y ago
      [deleted]
    - mkj 7y ago
      The keys themselves are not bound to sha1 or sha256. The hash is just used for the ephemeral signatures during authentication (or certificates as mentioned in the release notes). "ssh-rsa" signature scheme at runtime (sha1) will be deprecated, but rsa keys themselves are fine (edit typo name)
      - tialaramex 7y ago
        Indeed, and so to actually use this $50k attack on SSH you'd need to somehow arrange for your target to pick random numbers you expected so that your attack works. But for clarity, OpenSSH isn't saying this can be used against SSH today - the deprecation is because we should abandon broken hashes before they actually cause us harm, not wait until after. Don't Walk Past.
        RL_Quine 7y ago
        People are still obviously using 1024 bit RSA keys which are more of a problem.
      - xorcist 7y ago
        Right. Most SSH keys are just keys, not hashes. The hash used for key exchange during authentication is something that is enforced by the server (and client) and not a property of the key. The option in ssh-keygen for a signature algorithm is for signing keys in an SSH CA. This is not something Github supports.
  - numlock86 7y ago
    > Just for fun, most users on Github have RSA keys exclusively. Rare ecdsa-sha2-nistp256 guy here. I'd welcome Brainpool, but support mostly boils down to NIST compromised curves on the majority of applications. sadface > Did you know that your SSH keys are public on Github? Wait, what? Github makes public keys public? Outrageous!
    - RL_Quine 7y ago
      It's not intuitive because there's really no need for it.
      - dspillett 7y ago
        No harm in it either though. Unless for some reason someone imports one into their authorized_keys (which presumably would require deliberate steps not random numbskullary) in which case there is a (low) risk as they have just given a dev access to an account said dev does not know exists.
        RL_Quine 7y ago
        What you described is quite literally a feature in Ubuntu Server. Type in a github username during the installer to import from github.com/%s.keys to /root/.ssh/authorized_keys.
        tialaramex 7y ago
        My instinct is that's actually safer than a "set your password and open SSH to the world" step.
        3fe9a03ccd14ca5 7y ago
        A cronjob on every one of my IoT crap devices, which sometimes stay stuffed in a shoebox without internet for years: @reboot root ssh-import-id gh:my-username That way when I want to tinker with one, it will pull down my newest GitHub once it reboots and I’ll be able to login. The GitHub key is always up to date.
  - pnutjam 7y ago
    Those are just the public portion of the key, not the private key.
    - RL_Quine 7y ago
      I didn't say they were private keys.
  - joeyh 7y ago
    github also appears to only have RSA and DSA host keys, the latter is already deprecated
- mongol 7y ago
  What does chosen-prefix mean?
  - aaronmdjones 7y ago
    It means that you can influence the result by controlling the first part of the input. In other words, you can find an x such that H(x) == H(y) (for x != y) if you get to control the beginning bytes of x and know (or control) the beginning bytes of y.
    - tialaramex 7y ago
      Nope. That's a second pre-image attack.
  - tialaramex 7y ago
    Chosen prefix means somebody doing this attack gets to pick the start of both the colliding documents. For example maybe I want two children's stories, one which starts "Donald was an innocent young boy," and the other begins "Steve was a corrupt old gangster," The attack will calculate suffixes for these two documents such that both documents have the same hash result. This means the attacker can then show some people a document about Donald, and others the one about Steve and if they rely on the same hash to validate that they're the same document they'd be fooled. Digital certificates are the most prominent way computers deliberately depend on this assumption which a collision attack makes untrustworthy.
    - _pmf_ 7y ago
      Honest question: has this any relevance outside of academia?
      - tialaramex 7y ago
        Sure. Consider the Web PKI ("SSL Certificates"). Suppose you have a web site pmf.example it is of course pretty easy to get yourself a certificate to make https://pmf.example/ https://pmf.example/ work, today for free but even many years ago it was pretty affordable from several commercial vendors. The way those certificates work is they use a digital signature based on a hash algorithm, the CA uses its private key to sign the hash, and that's how computers can immediately tell a real certificate from a bogus one and be sure this is really news.ycombinator.com and not say, your ISP's advertising front end injecting a "special offer". The CA will refuse to give you a certificate for google.com or news.ycombinator.com because those aren't yours. But using a chosen prefix attack you can create two documents with the same hash. One of them might be a fairly ordinary looking certificate for pmf.example that you're entitled to, the other says you're google.com You get a CA to sign the first certificate, then you simply snip off their signature and attach it to the second one, since their hashes are the same the signature matches. You now have a valid certificate for google.com. Not theory, practice, this was really done with an earlier broken hash, MD5. e.g. https://hackaday.com/2008/12/30/25c3-hackers-completely-break-ssl-using-200-ps3s/ https://hackaday.com/2008/12/30/25c3-hackers-completely-brea... A similar trick, probably done by or on behalf of the US and/or Israeli governments makes Flame work by colliding MD5 for code signing. That uses a collision nobody publicly knew about, which is a weird and expensive thing to do but of course governments have lots of money. https://en.wikipedia.org/wiki/Flame_(malware) https://en.wikipedia.org/wiki/Flame_(malware)
- nextweek2 7y ago
  Oh deer, perhaps someone at Microsoft DevOps should be told. https://developercommunity.visualstudio.com/idea/365980/support-non-rsa-keys-for-ssh-authentication.html https://developercommunity.visualstudio.com/idea/365980/supp...
  - deleted 7y ago
    [deleted]
  - aepiepaey 7y ago
    This is not about RSA keys - they're still fine. See https://news.ycombinator.com/item?id=22324492 https://news.ycombinator.com/item?id=22324492 and https://news.ycombinator.com/item?id=22324535 https://news.ycombinator.com/item?id=22324535
- Steltek 7y ago
  Can this be more simply achieved using the "KexAlgorithms" and "MACs" config settings for /etc/ssh/sshd_config and ~/.ssh/config ?
  - jlgaddis 7y ago
    Sure, just remove "ssh-rsa" from the "HostKeyAlgorithms" list in /etc/ssh/sshd_config. For example, you might instead use: HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256 Myself, I've long set the (client-side) defaults on my workstations to HostKeyAlgorithms ssh-ed25519,ssh-rsa but it looks like it may be time to update that.
_-___________-_ 7y ago
Notable in this release is support for generating and using keys backed by FIDO/U2F tokens (and, with supported tokens, keys fully resident in FIDO/U2F tokens that you can transport between computers).
- philcrump 7y ago
  I'm happy to see this, however I'd be far more excited if I thought there was a chance of it landing in the upcoming Ubuntu 20.04 release - else I'll likely be waiting impatiently until 22.04 for server-side support.
  - oarsinsync 7y ago
    It'll probably make its way into the backports repo. While that does add some complexity to managing your system, it may be worth it in this instance. YMMV.
  - georgeam 7y ago
    Likewise, I would be glad to see it in 20.04. According to this page, https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule, feature freeze for 20.04 is on the 27th of February so I don't see any reason why Openssh 8.2 can't make it into the LTS. Unless there are other considerations I'm not aware of.
- gnufx 7y ago
  Does anyone know whether what was raised in https://news.ycombinator.com/item?id=21419015 https://news.ycombinator.com/item?id=21419015 was addressed, as the thread didn't get updated?
- krabelize 7y ago
  Works smoothly: https://cryptsus.com/blog/how-to-configure-openssh-with-yubikey-security-keys-u2f-otp-authentication-ed25519-sk-ecdsa-sk-on-ubuntu-18.04.html https://cryptsus.com/blog/how-to-configure-openssh-with-yubi...
danieldk 7y ago
The FIDO/U2F support is really nice! Though I had a question about this: is it only necessary for the client to use an OpenSSH version (>= 8.2) that supports this, or should the server also have support?
- tulir 7y ago
  I'm pretty sure the server also needs to support it. The U2F signature stuff is different from SSH, so it needs a new authentication protocol: https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.u2f#L11-L14 https://github.com/openssh/openssh-portable/blob/master/PROT...
  - danieldk 7y ago
    You are right. There is also more information here: https://marc.info/?l=openssh-unix-dev&m=157259802529972&w=2 https://marc.info/?l=openssh-unix-dev&m=157259802529972&w=2 This step is very straightforward; append the public key to authorized_keys as you would normally. Note that U2F keys are a new OpenSSH key type, so the server must support it too. I guess it will take a few years until all servers are upgraded.
deleted 7y ago
[deleted]
throw0101a 7y ago
Perhaps change the link to the official ChangeLog? * https://www.openssh.com/txt/release-8.2 https://www.openssh.com/txt/release-8.2
linsomniac 7y ago
As a (very) longtime user of SSH, are there any features in (relatively) newer releases that have changed peoples lives? Last year I switched over to using signed SSH host keys, and for my fleet of ~150 VMs, some of which respin on a nightly basis, this has been a game changer. No longer do I need to keep a master "known_hosts" file updated and distributed across the fleet.
- exabrial 7y ago
  Yes! Read the realease notes on U2F keys as SSH Keys; this means a cheap ($5-$25 USD) hardware key can now be used as an ssh key! These physical keys require a tap or physical touch to release a signature and are hardened against physical attack.
maratc 7y ago
> Fortunately, RSA using SHA1 is not a problem here because the value being signed is actually a SHA2 hash. The hash function SHA1(SHA2(x)) is just as secure as SHA2 (it has less bits of course but no better attacks). From: https://stribika.github.io/2015/01/04/secure-secure-shell.html https://stribika.github.io/2015/01/04/secure-secure-shell.ht...

118 points by beefhash 7y ago

Notably from the changelog: 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.

RL_Quine 7y ago
Just for fun, most users on Github have RSA keys exclusively. Did you know that your SSH keys are public on Github? https://github.com/taylorotwell.keys https://github.com/taylorotwell.keys https://github.com/alexcrichton.keys https://github.com/alexcrichton.keys https://github.com/andrew.keys https://github.com/andrew.keys https://github.com/egoist.keys https://github.com/egoist.keys https://github.com/fabpot.keys https://github.com/fabpot.keys Some of the most popular users even have DSS keys.
- egyiedfyfrtjjf 7y ago
  As a RSA-user myself, because I learnt about ssh through the github setup guides: Will ssh-keygen generate a secure key if I don’t pass it any parameters?
  - RL_Quine 7y ago
    I haven't built the new version, but I assume it defaults to ed25519 now. You can otherwise make one with ssh-keygen -t ed25519.
    - techntoke 7y ago
      Last time I tried AWS doesn't support anything but RSA keys.
      - RL_Quine 7y ago
        That’s right. Nothing stopping you having both though.
      - zenexer 7y ago
        They don’t need to. Boot up a default AMI, change the key to whatever you want, then create your own custom AMI from that. Or you can use something like Cloud-Init.
      - lawnchair_larry 7y ago
        This is good news, because AWS will finally be forced to get with the times. Their certificate manager is stuck on RSA too.
  - jlgaddis 7y ago
    It will generate a 2048-bit RSA keypair by default. It will be "a secure key" as long as you protect it with an appropriate passphrase.
    - gnufx 7y ago
      You need recent ssh-keygen's -o to make the passphprase effective (default for ed25519). That was covered here at some stage, but I don't have a reference.
- zimmerfrei 7y ago
  You are conflating RSA (the algorithm) with "ssh-rsa" (the option of the SSH suite indicating authentication with RSA in combination with SHA-1). They deprecate the latter. Other options also based on RSA such as "rsa-sha2-256/512" are fine and will remain supported. In other words, the security problem is not with RSA per se. Having said that, I have not checked whether the people you list have RSA keys bound to SHA-1...
  - deleted 7y ago
    [deleted]
  - mkj 7y ago
    The keys themselves are not bound to sha1 or sha256. The hash is just used for the ephemeral signatures during authentication (or certificates as mentioned in the release notes). "ssh-rsa" signature scheme at runtime (sha1) will be deprecated, but rsa keys themselves are fine (edit typo name)
    - tialaramex 7y ago
      Indeed, and so to actually use this $50k attack on SSH you'd need to somehow arrange for your target to pick random numbers you expected so that your attack works. But for clarity, OpenSSH isn't saying this can be used against SSH today - the deprecation is because we should abandon broken hashes before they actually cause us harm, not wait until after. Don't Walk Past.
      - RL_Quine 7y ago
        People are still obviously using 1024 bit RSA keys which are more of a problem.
    - xorcist 7y ago
      Right. Most SSH keys are just keys, not hashes. The hash used for key exchange during authentication is something that is enforced by the server (and client) and not a property of the key. The option in ssh-keygen for a signature algorithm is for signing keys in an SSH CA. This is not something Github supports.
- numlock86 7y ago
  > Just for fun, most users on Github have RSA keys exclusively. Rare ecdsa-sha2-nistp256 guy here. I'd welcome Brainpool, but support mostly boils down to NIST compromised curves on the majority of applications. sadface > Did you know that your SSH keys are public on Github? Wait, what? Github makes public keys public? Outrageous!
  - RL_Quine 7y ago
    It's not intuitive because there's really no need for it.
    - dspillett 7y ago
      No harm in it either though. Unless for some reason someone imports one into their authorized_keys (which presumably would require deliberate steps not random numbskullary) in which case there is a (low) risk as they have just given a dev access to an account said dev does not know exists.
      - RL_Quine 7y ago
        What you described is quite literally a feature in Ubuntu Server. Type in a github username during the installer to import from github.com/%s.keys to /root/.ssh/authorized_keys.
        tialaramex 7y ago
        My instinct is that's actually safer than a "set your password and open SSH to the world" step.
        3fe9a03ccd14ca5 7y ago
        A cronjob on every one of my IoT crap devices, which sometimes stay stuffed in a shoebox without internet for years: @reboot root ssh-import-id gh:my-username That way when I want to tinker with one, it will pull down my newest GitHub once it reboots and I’ll be able to login. The GitHub key is always up to date.
- pnutjam 7y ago
  Those are just the public portion of the key, not the private key.
  - RL_Quine 7y ago
    I didn't say they were private keys.
- joeyh 7y ago
  github also appears to only have RSA and DSA host keys, the latter is already deprecated
mongol 7y ago
What does chosen-prefix mean?
- aaronmdjones 7y ago
  It means that you can influence the result by controlling the first part of the input. In other words, you can find an x such that H(x) == H(y) (for x != y) if you get to control the beginning bytes of x and know (or control) the beginning bytes of y.
  - tialaramex 7y ago
    Nope. That's a second pre-image attack.
- tialaramex 7y ago
  Chosen prefix means somebody doing this attack gets to pick the start of both the colliding documents. For example maybe I want two children's stories, one which starts "Donald was an innocent young boy," and the other begins "Steve was a corrupt old gangster," The attack will calculate suffixes for these two documents such that both documents have the same hash result. This means the attacker can then show some people a document about Donald, and others the one about Steve and if they rely on the same hash to validate that they're the same document they'd be fooled. Digital certificates are the most prominent way computers deliberately depend on this assumption which a collision attack makes untrustworthy.
  - _pmf_ 7y ago
    Honest question: has this any relevance outside of academia?
    - tialaramex 7y ago
      Sure. Consider the Web PKI ("SSL Certificates"). Suppose you have a web site pmf.example it is of course pretty easy to get yourself a certificate to make https://pmf.example/ https://pmf.example/ work, today for free but even many years ago it was pretty affordable from several commercial vendors. The way those certificates work is they use a digital signature based on a hash algorithm, the CA uses its private key to sign the hash, and that's how computers can immediately tell a real certificate from a bogus one and be sure this is really news.ycombinator.com and not say, your ISP's advertising front end injecting a "special offer". The CA will refuse to give you a certificate for google.com or news.ycombinator.com because those aren't yours. But using a chosen prefix attack you can create two documents with the same hash. One of them might be a fairly ordinary looking certificate for pmf.example that you're entitled to, the other says you're google.com You get a CA to sign the first certificate, then you simply snip off their signature and attach it to the second one, since their hashes are the same the signature matches. You now have a valid certificate for google.com. Not theory, practice, this was really done with an earlier broken hash, MD5. e.g. https://hackaday.com/2008/12/30/25c3-hackers-completely-break-ssl-using-200-ps3s/ https://hackaday.com/2008/12/30/25c3-hackers-completely-brea... A similar trick, probably done by or on behalf of the US and/or Israeli governments makes Flame work by colliding MD5 for code signing. That uses a collision nobody publicly knew about, which is a weird and expensive thing to do but of course governments have lots of money. https://en.wikipedia.org/wiki/Flame_(malware) https://en.wikipedia.org/wiki/Flame_(malware)
nextweek2 7y ago
Oh deer, perhaps someone at Microsoft DevOps should be told. https://developercommunity.visualstudio.com/idea/365980/support-non-rsa-keys-for-ssh-authentication.html https://developercommunity.visualstudio.com/idea/365980/supp...
- deleted 7y ago
  [deleted]
- aepiepaey 7y ago
  This is not about RSA keys - they're still fine. See https://news.ycombinator.com/item?id=22324492 https://news.ycombinator.com/item?id=22324492 and https://news.ycombinator.com/item?id=22324535 https://news.ycombinator.com/item?id=22324535
Steltek 7y ago
Can this be more simply achieved using the "KexAlgorithms" and "MACs" config settings for /etc/ssh/sshd_config and ~/.ssh/config ?
- jlgaddis 7y ago
  Sure, just remove "ssh-rsa" from the "HostKeyAlgorithms" list in /etc/ssh/sshd_config. For example, you might instead use: HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256 Myself, I've long set the (client-side) defaults on my workstations to HostKeyAlgorithms ssh-ed25519,ssh-rsa but it looks like it may be time to update that.

_-___________-_ 7y ago

Notable in this release is support for generating and using keys backed by FIDO/U2F tokens (and, with supported tokens, keys fully resident in FIDO/U2F tokens that you can transport between computers).

philcrump 7y ago
I'm happy to see this, however I'd be far more excited if I thought there was a chance of it landing in the upcoming Ubuntu 20.04 release - else I'll likely be waiting impatiently until 22.04 for server-side support.
- oarsinsync 7y ago
  It'll probably make its way into the backports repo. While that does add some complexity to managing your system, it may be worth it in this instance. YMMV.
- georgeam 7y ago
  Likewise, I would be glad to see it in 20.04. According to this page, https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule, feature freeze for 20.04 is on the 27th of February so I don't see any reason why Openssh 8.2 can't make it into the LTS. Unless there are other considerations I'm not aware of.
gnufx 7y ago
Does anyone know whether what was raised in https://news.ycombinator.com/item?id=21419015 https://news.ycombinator.com/item?id=21419015 was addressed, as the thread didn't get updated?
krabelize 7y ago
Works smoothly: https://cryptsus.com/blog/how-to-configure-openssh-with-yubikey-security-keys-u2f-otp-authentication-ed25519-sk-ecdsa-sk-on-ubuntu-18.04.html https://cryptsus.com/blog/how-to-configure-openssh-with-yubi...

danieldk 7y ago

The FIDO/U2F support is really nice! Though I had a question about this: is it only necessary for the client to use an OpenSSH version (>= 8.2) that supports this, or should the server also have support?

tulir 7y ago
I'm pretty sure the server also needs to support it. The U2F signature stuff is different from SSH, so it needs a new authentication protocol: https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.u2f#L11-L14 https://github.com/openssh/openssh-portable/blob/master/PROT...
- danieldk 7y ago
  You are right. There is also more information here: https://marc.info/?l=openssh-unix-dev&m=157259802529972&w=2 https://marc.info/?l=openssh-unix-dev&m=157259802529972&w=2 This step is very straightforward; append the public key to authorized_keys as you would normally. Note that U2F keys are a new OpenSSH key type, so the server must support it too. I guess it will take a few years until all servers are upgraded.

deleted 7y ago

[deleted]

throw0101a 7y ago

Perhaps change the link to the official ChangeLog? * https://www.openssh.com/txt/release-8.2 https://www.openssh.com/txt/release-8.2

linsomniac 7y ago

As a (very) longtime user of SSH, are there any features in (relatively) newer releases that have changed peoples lives? Last year I switched over to using signed SSH host keys, and for my fleet of ~150 VMs, some of which respin on a nightly basis, this has been a game changer. No longer do I need to keep a master "known_hosts" file updated and distributed across the fleet.

exabrial 7y ago
Yes! Read the realease notes on U2F keys as SSH Keys; this means a cheap ($5-$25 USD) hardware key can now be used as an ssh key! These physical keys require a tap or physical touch to release a signature and are hardened against physical attack.

maratc 7y ago

> Fortunately, RSA using SHA1 is not a problem here because the value being signed is actually a SHA2 hash. The hash function SHA1(SHA2(x)) is just as secure as SHA2 (it has less bits of course but no better attacks). From: https://stribika.github.io/2015/01/04/secure-secure-shell.html https://stribika.github.io/2015/01/04/secure-secure-shell.ht...