openssh unix dev - Oct 2020 - Future deprecation of ssh-rsa

For the last few releases, there has been a notice that ssh-rsa will be
deprecated in a near-future release. Is there a target release for this
deprecation to take effect? I saw in the 8.4 release notes that?UpdateHostKeys
is going to be default enabled in the next release to prepare for this. Is it
likely that 8.6 will deprecate ssh-rsa after a release cycle of UpdateHostKeys
being default or are we likely talking further in the future than that?

I apologize if this has been asked before and I've missed it. I've tried
reading threads that looked relevant and did not see the answer.


Thanks,
Alex

Alex,

Because you ask about UpdateHostKeys I think there might be a common
misunderstanding behind your post.  Apologies if I assumed wrongly!

RSA keys are not going away, and will continue to be supported.

'ssh-rsa' is the prefix used for the public keys as stored on disk,
but that on-disk key format is not what's being deprecated.

While this isn't obvious to those who aren't well-versed in SSH wire
protocol internals, in the context of the deprecation, 'ssh-rsa'
refers only to the ephemeral, over-the-wire signature algorithm used
to validate the client's possession of the key.

As long as both the client and server support the newer signature
algorithms like 'rsa-sha2-256' or 'rsa-sha2-512', your RSA keys
will
continue to work.  (Also, the 'ssh-rsa' prefix is still used for the
key, even though the signature algorithm is now named differently.)

The necessary signature algorithm support was added in OpenSSH 7.2.

I hope this helps,

-- 
Chris Danis (he/him)
Staff Site Reliability Engineer
Wikimedia Foundation

Chris,
Thanks for the response! Maybe I shouldn't have mentioned UpdateHostKeys in
my post. I only mentioned it because it is referenced in a way that I read as a
part of the strategy to deprecate ssh-rsa - in the release notes for 8.4 and in
a previous post regarding the deprecation notice: "We're still one or
two steps away ATM, e.g. we still need to fix the corner cases in UpdateHostkeys
and enable it)". My possibly faulty reading of context there was that these
were steps leading up to the deprecation.?


I am perhaps imprecise and mis-communicating my understanding of the deprecation
because I don't speak the language of ssh as well as some on here. My
understanding, which I think is what you are highlighting in your response is
that the deprecation is limited the sha1 based ssh-rsa signature algorithm. I
understand rsa-sha2-256 and rsa-sha2-512 to be the sha2 alternatives which are
continuing support. I'm sorry if I am still missing what you are saying. I
actually rather appreciate the way you described it in a clarity I struggle to
boil it down to as I just don't spend enough time in the ssh land(as you
rightly surmised).


Thank you,
Alex






On Tuesday, October 20, 2020, 08:25:58 PM EDT, Chris Danis <cdanis at
wikimedia.org> wrote:





Alex,


Because you ask about UpdateHostKeys I think there might be a common
misunderstanding behind your post.? Apologies if I assumed wrongly!

RSA keys are not going away, and will continue to be supported.

'ssh-rsa' is the prefix used for the public keys as stored on disk,
but that on-disk key format is not what's being deprecated.

While this isn't obvious to those who aren't well-versed in SSH wire
protocol internals, in the context of the deprecation, 'ssh-rsa'
refers only to the ephemeral, over-the-wire signature algorithm used
to validate the client's possession of the key.

As long as both the client and server support the newer signature
algorithms like 'rsa-sha2-256' or 'rsa-sha2-512', your RSA keys
will
continue to work.? (Also, the 'ssh-rsa' prefix is still used for the
key, even though the signature algorithm is now named differently.)

The necessary signature algorithm support was added in OpenSSH 7.2.

I hope this helps,

-- 
Chris Danis (he/him)
Staff Site Reliability Engineer
Wikimedia Foundation
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Wed, 21 Oct 2020, Alex Harrison wrote:
> For the last few releases, there has been a notice that ssh-rsa will
> be deprecated in a near-future release. Is there a target release
> for this deprecation to take effect? I saw in the 8.4 release notes
> that?UpdateHostKeys is going to be default enabled in the next release
> to prepare for this. Is it likely that 8.6 will deprecate ssh-rsa
> after a release cycle of UpdateHostKeys being default or are we likely
> talking further in the future than that?
>
> I apologize if this has been asked before and I've missed it. I've
> tried reading threads that looked relevant and did not see the answer.
No, we haven't set a target date yet. It really depends on how well
turning on UpdateHostKeys goes, how quickly a release with UpdateHostKeys
ends up on common OS distributions and a couple of other things.

What we'll probably do is start by turning off ssh-rsa in git HEAD at
after the next release, and leave it off until close to the next release.
This will give people who use OpenSSH HEAD (e.g. the users of OpenBSD
-current) some experience with the practical impact of the change while
we're giving time for UpdateHostKeys to reach a wider population and do
its thing.

-d

I've expressed several concerns with enabling UpdateHostKeys by default,
none of which were even commented on, so this topic seems to not be in
any way open for discussion, but I'll still add one more thing here.

Peter Stuge wrote:
> Subject: Re: UpdateHostkeys now enabled by default
> Date: Mon, 5 Oct 2020 11:22:29 +0000
..
> I do not disagree with progressive key management, we clearly need to
> roll keys now and then, and I'm also not against some automation, but
> I don't think that it should be fully automated.
..
> Host keys are quite stable and I think that's a good thing.

Damien Miller wrote:
> No, we haven't set a target date yet. It really depends on how well
> turning on UpdateHostKeys goes, how quickly a release with UpdateHostKeys
> ends up on common OS distributions and a couple of other things.
Beyond strongly disagreeing with clients silently accepting and persisting
unsolicited configuration changes from servers by default, I would like to
see differentiation between a couple of different UpdateHostKeys cases:

* from ssh-rsa to rsa-sha2-* without the host key changing
* from ssh-rsa to either ssh-rsa or rsa-sha2-* with a *new host key*, and
* from ssh-rsa to say ssh-ed25519 with a *new public host key algorithm*

I don't think that these three cases can reasonably be considered
to ever have the same, or even comparable, security properties. Do you?


//Peter