OpenSSH 8.4 | Hacker News Reader

OpenSSH 8.4

marc.info

192 pointsfrutiger45 comments

There seems to be some confusion about what the disabling of the "ssh-rsa" public key signature algorithm actually means. This does not mean that you will need to generate new non-rsa keys (although that isn't a bad idea).

The on disk key format that you see in your authorized_keys that begins with "ssh-rsa" is just the RSA key (it doesn't encode anything about the hashing algorithm). You will be able to continue to use that key with the "rsa-sha2-256" and "rsa-sha2-512" algorithms. The details of this are outlined in Section 3 of RFC8332[0].

[0]: https://tools.ietf.org/html/rfc8332#section-3

That may be true, but you'll need to update you public key anywhere you use the `ssh-rsa` method; i.e. my github public keys[1] will all need updating.

I use this set, statically copied, in most of my various machines and logins. You can generate a `rsa-sha2-512` public key for your existing private key, but for most people the update is less confusing to generate a new key than to use a new private key. Only in scenarios where you have the same private key across several machines do you save any time, and I (and security professionals) have been advising against that for ages.

[1] https://github.com/gauntletwizard.keys

This is not true, for client keys ssh-rsa is just fine.

If you're using certificates then you may need to get those resigned. But most people aren't using certificates, just bare rsa keys.

And ssh-rsa client keys don't specify a hashing algo at all. Even if you specified `-t rsa-sha2-512` it would still output a ssh-rsa .pub.

The section of the RFC linked in the comment you're replying to even explicltly states:

> All aspects of the "ssh-rsa" format are kept, including the encoded string "ssh-rsa". This allows existing RSA keys to be used with the new public key algorithms, without requiring re-encoding or affecting already trusted key fingerprints.

> scp(1), sftp(1): allow the -A flag to explicitly enable agent forwarding in scp and sftp. The default remains to not forward an agent, even when ssh_config enables it.

How could one use agent forwarding with sftp? I guess for scp I can imagine a contrived example like `scp -AT server:'$(ssh server2 generate-paths)' .`, but for sftp? sftp doesn't seem to have a way to run an ssh client on the remote side, and it's not like agent-forwarding is needed for `-J`/`ProxyJump`.

The SFTP subsystem on the remote end might be replaced with something custom that utilizes the forwarded agent. Perhaps a gateway SFTP server to a NAS that needs forwarded credentials?

You can do a quick audit from your $SHELL against your SSH server over network using ssh-audit.sh.

https://github.com/jtesta/ssh-audit

Some comments here seem to focus on the “Future deprecation notice” of the ssh-rsa signatures. That’s been there for a few releases this year, still not in effect.

https://www.openssh.com/releasenotes.html

The big improvements here are in more support for FIDO2, but the config file env var interpretation smarts are very welcome.

The ability to require UV is nice.

A FIDO2 authenticator doesn't really "understand" most of what it signs, it's basically handed a blob by the big smart computer and signs that blob, which allows your web browser to add new features to WebAuthn without you having to buy a new Yubikey every week.

But the authenticator does also sign a small pile of bit flags with a meaning clearly defined for the authenticator's use, one of those flags (UP: User present) is defined to mean "I promise a human interacted with me somehow to signify presence" (e.g. "they pressed a button") and another (UV: User verified) means "I promise I verified the key's owner authorised this signature" (e.g. "I checked their PIN" or "The fingerprint matched")

So these bitflags are very trustworthy, the smarter and thus more vulnerable host application can't change them without consent by the authenticator. If my Yubico Security Key doesn't see my correct PIN, an adversary needs to subvert the actual Security Key if they want the UV bit set, just controlling my PC or phone doesn't help them do that.

Thus, this feature in OpenSSH will let justifiably paranoid administrators decide it's OK to use this FIDO2 key to log into this production server but only if the key promises that it checked its legitimate owner authorised this.

The number of corrections in the comments here shows how complex this stuff is.

While I agree this stuff is complex, the patch notes are the only real problem here.

Almost all the corrections are around the '"ssh-rsa" public key signature algorithm' deprecation. The string "ssh-rsa" is used in many places, and has different meanings in different places. The notes should have been much more explicit about what is and what is not affected.

To be fair the vast majority of corrections here, and everywhere else, and for every recent version are always exactly the same. No your RSA keys don't need to be replaced, which is why this article says they don't need to be replaced, because they don't need to be replaced.

So you're only talking about volume of the same correction being repeated, not distinct corrections.

For the TLDR of this, I think the major point is the depreciation of ssh-rsa keys. They recommend switching to SHA2 with either ed25519 or the NIST P curves. They acknowledge the large amount of existing keys out there using RSA as a challenge.

Incorrect. RSA keys are fine, the ssh-rsa key signature algorithm is not. You can instead use the rsa-sha2-256 signature algorithm with your RSA keys (and you will have been using this for some time if you are running non-ancient openssh).

As pointed out in other comments, it's not the case. It's deprecating an insecure way to use RSA keys to perform crypto operations.

RSA keys themselves continue to be secure.

Looks like they broke every old setup again?

It might or not might make things more secure, but it will definitely cause a lot of pain.

I wish they would leave that choice to me.

Just a little humble correction in case the author is reading:

It says "The RFC5656 ECDSA algorithms: ecdsa-sha2-nistp256/384/521." I think the last bit should be 512, not 521.

No, surprisingly that curve is actually called NIST P-521.

Nope, nistp521 is the correct name for the curve.

No, it's actually 521. I had some people helpfully trying to "correct" this to 512 in the past, it's a common attitude when seeing this for the first time ;) See for reference section G.1.4 page 58:

  https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-186-draft.pdf

  "The modulus for this curve is p = 2^521 – 1".

Oh, that's weird. Sorry. As it went 256 384 I thought it was 512 intuitively.

Daniel J. Bernstein actually regards the 521 curve as the only secure NIST curve, asserting that the 256 and 384 curves have too many suspicious and unexplained terms.

"To be fair I should mention that there's one standard NIST curve using a nice prime, namely 2^521 – 1; but the sheer size of this prime makes it much slower than NIST P-256."

http://blog.cr.yp.to/20140323-ecdsa.html

The release notes describe how to test authentication without SHA-1 on a SSH server. In my case, it was more useful to check the algorithm of my SSH keys to check if they were to be obsolete:

    $ ssh-keygen -l -f MyKeyFile
    2048 SHA256:39XX..XX x@y.com  (RSA)
    $ for f in ~/.ssh/*.pub; do ssh-keygen -l -f $f; done

All of my keys were using ED25519 or RSA-SHA256, so they will still be valid when RSA-SHA1 will be removed.

Note that Debian Strech (oldstable, published in 2017) shipped openssh-client 7.4 which produced RSA SHA-256 keys by default.

Your client ssh-rsa keys do not specify a hashing algo at all unless they are signed certificates.

The vast majority of client ssh-rsa keys are completely unaffected since they are bare rsa keys with no hashing done at all.

That sha256 is just the fingerprint of the key. It's calculated, not stored in the file.

From Github data, the overwhelming majority of all SSH keys added by users are ssh-rsa, which will be disallowed soon for older clients. Mind you there still a number of users with ssh-dss which is just comical.

Remember that you can download the SSH public keys of any user on Github and run these statistics yourself.

    https://github.com/linus.keys

Linus for example seems to have two keys, a 1024 bit RSA and a 2048 bit RSA.

No, the keys themselves are fine, and are not going to be "disallowed". Its the SHA-1 part of the signature algorithm that is the problem. Fortunately you can use SHA-2 with your existing "ssh-rsa" keys, as the release notes clearly say:

> The better alternatives include:

> The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These algorithms have the advantage of using the same key type as "ssh-rsa" but use the safe SHA-2 hash algorithms. These have been supported since OpenSSH 7.2 and are already used by default if the client and server support them.

Honest question: is there any reason for using RSA for new keys these days, if you are not working with extremely legacy systems? My ed25519 works fine with at least CentOS 7, and thankfully that's the oldest system I have to touch.

Maybe only if you want to store the key on a separate physical device, and it only supports RSA?

If you are generating a new keypair, you should default to ed25519. There are still a number of openpgp/smartcard devices that only support RSA keys.

Edit: Another reason one might still use RSA keys: ed25519 isn't a FIPS-140 approved algorithm (yet).

To be fair, “because it is FIPS-140 approved” is also a reason some people give for avoiding an algorithm.

There's zero reason to ever use RSA for SSH keys, certainly.

AWS for some reason only supports RSA keys...

Those are needed for example to push code to their managed git (CodeCommit) and if you want a key added when you launch an EC2 machine and to fetch the Windows password.

Is there a reason for AWS being stuck with RSA? It's not like they lack money or engineering talent.

Azure only supported RSA keys last time I checked.

Why not? RSA is perfectly secure and more compatible. Short public key is nice, but does not matter much in reality as you'll copy&paste it anyway.

RSA 1024, which is supported, is not what anybody would call "perfectly secure".

RSA 1024 is still almost perfectly secure in practice. Something like the NSA might be able to break it only after the expenditure of years of work and zillions of dollars.

But beside the point as we are talking about RSA 2048 here which is in fact "perfectly secure" and the public key is not the part subject to downgrade attacks.

Breaking a 1024-bit RSA key for SSH is a lot of effort for a very minimal reward.

The benefit if you do this is now you can impersonate the key's owner for new connections. So if it's a host key you can pretend to be that host if you're able to get on path between a victim and the real host, if it's a user key you can log in as that user with public key authentication.

But that's an active attack and an expensive key break.

Breaking 1024-bit RSA for HTTPS servers was a much juicier target because you can passively snoop RSA kex in TLS 1.2 and older. But that's not a thing in SSH, it's active attacks only.

The physical auth devices survive a lot and will last for years / decades. Quite a few of them supported only RSA keys, so don't expect it to go away any time soon.

My almost 10yo yubi still works just fine.

FTA:

>The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These algorithms have the advantage of using the same key type as "ssh-rsa" but use the safe SHA-2 hash algorithms. These have been supported since OpenSSH 7.2 and are already used by default if the client and server support them.

It's unclear to me whether I'm using SHA1 or SHA2. Running ` ssh -oHostKeyAlgorithms=-ssh-rsa ` against one of my servers works, and I'm sure to have created my key before 2016 when OpenSSH 7.2 was released.

If you run with -vv during auth there's some debug text to do with cryptography selection. In the case of github the response is:

    debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss>

Which suggests you'll be using rsa-sha2-256 with your client version, or absolutely nothing in the future if you're using one of the older releases such as on MacOS.

It doesn't matter when you created your key. This is protocol stuff. If you're using non-ancient OpenSSH, and the server is using non-ancient OpenSSH, and you haven't done anything silly like disable the sha2 signature algorithms, then you're already using them since they're preferred by default.

Unless you're using certificates, your rsa keys don't specify any hashing algo at all. The negotiating between the client and server decide the signature algo.

> From Github data, the overwhelming majority of all SSH keys added by users are ssh-rsa, which will be disallowed soon. Mind you there still a number of users with ssh-dss which is just comical.

It seems that this is partially the fault of all the big git hosts "guides" for new beginners.

GitHub's guide shows how to create an RSA key. [3] There's no information about why you would choose RSA or anything else. You're expected to make an RSA key.

Atlassian's guide shows how to create an RSA key. [0] They at least spell out there are other options, but DSA is the first of them, and they don't say anything about the types.

The GitBook isn't as specific in the commands it says to use, but shows RSA as the output. [1]

GitLab actually doesn't recommend RSA, and spells out the choice a bit more than most, but that seems like a recent change. [2] Props to them.

[0] https://confluence.atlassian.com/bitbucketserver/creating-ss...

[1] https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-...

[2] https://docs.gitlab.com/ee/ssh/

[3] https://docs.github.com/en/free-pro-team@latest/github/authe...

Reply on news.ycombinator.com