
OpenSSH 8.2 - beefhash
https://lists.mindrot.org/pipermail/openssh-unix-announce/2020-February/000138.html
======
beefhash
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
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.

~~~
zimmerfrei
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...

~~~
mkj
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
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
People are still obviously using 1024 bit RSA keys which are more of a
problem.

------
_-___________-_
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
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.

~~~
georgeam
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.

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

------
danieldk
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
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/PROT...](https://github.com/openssh/openssh-
portable/blob/master/PROTOCOL.u2f#L11-L14)

~~~
danieldk
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.

------
throw0101a
Perhaps change the link to the official ChangeLog?

* [https://www.openssh.com/txt/release-8.2](https://www.openssh.com/txt/release-8.2)

------
maratc
> 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.ht...](https://stribika.github.io/2015/01/04/secure-secure-shell.html)

