An update on SSH protocol 1

[Damien Miller]

Hi,

At this stage, we're most of the way towards fully deprecating
SSH protocol 1 - this outlines our plans to complete this task.

We've had this old protocol in various stages of deprecation for almost
10 years and it has been compile-time disabled for about a year.
Downstream vendors, to their credit, have included this change in recent
OS releases by shipping OpenSSH packages that disable protocol 1 by
default and/or offering separate, non-default packages to enable it.

This seems to have proceeded far more smootly than even my most
optimisitic hopes, so this gives us greater confidence that we can
complete the removal of protocol 1 soon. We want to do this partly to
hasten the demise of this cryptographic trainwreck, but also because
doing so removes a lot of legacy code from OpenSSH that inflates our
attack surface. Having it gone will make our jobs quite a bit easier
as we maintain and refactor.

So here are our plans. Dates are estimates only.

* June 2016

Release OpenSSH 7.3. SSH protocol 1 is unchanged. We start mention
these plans in the release notes to give them wider publicity.

* August 2016

Release OpenSSH 7.4. Server-side support for SSHv1 is removed from
our codebase. Client support remains disabled by default.

* June 2017

OpenSSH removes all SSH protocol 1 support.

--

So this is just over a year of notice ahead of final deprecation. After
we release OpenSSH without SSHv1 support, users who absolutely need it
would have to use a prior version of OpenSSH or some other
implementation.

We recognise that this may leave some users without a supported client
for their protocol v1 hosts, but we feel that >10 years of transition
is time enough.

Feedback is welcome.

Cheers,
Damien Miller (on behalf of the team)

[Damien Miller]

Debian takes the latter approach. Specifically, we have an
"openssh-client-ssh1" binary package that includes only scp1, ssh1, and
ssh-keygen1 binaries; we do not ship any server-side SSHv1 support. I
modelled this on Fedora's approach, which is basically the same aside
from a slightly different package name.
A number of our users are basically stuck needing to interoperate with
SSHv1-only servers that they can't update for one reason or another.
Obviously this is a pretty broken world, but maybe they're at least
behind a VPN or firewalled to the local network or something and at any
rate I'm rather glad that none of those things are directly my problem.
My plan for Debian (and thus Ubuntu etc.) is therefore that, once SSHv1
is entirely removed from OpenSSH, I will split out the
openssh-client-ssh1 binary package to be built from a separate source
package which will remain frozen at the last OpenSSH release that
supported SSHv1. As before, this will ship only scp1, ssh1, and
ssh-keygen1 binaries.
If I notice any fixes for client-side vulnerabilities that might affect
SSHv1, then I'll backport them on a best-effort basis, but I expect this
to be rare. The protocol is sufficiently broken anyway that I'm not
going to lose much sleep over it. I've had it suggested to me that I
should try to strip it down further (e.g. removing X forwarding
capability), but on the whole I think the chances of accidentally
breaking something as a result in something I don't myself use outweigh
the expected benefits.
Any comments on this? Feedback from the changes in 7.0 has convinced me
that Debian does need to keep shipping basic client-side support in some
form, but it can be very minimal and I'm happy to put whatever dire
warnings on it seem useful and appropriate.
Notwithstanding all this, the plan of removing all this obsolete code
from OpenSSH proper makes a lot of sense to me and I have no complaints
there.

Your plan sounds emminently reasonable and I'll repeat my thanks
for your helping the transition by making separate -ssh1 packages.


-d

[Colin Watson]

Post by Damien Miller
We've had this old protocol in various stages of deprecation for almost
10 years and it has been compile-time disabled for about a year.
Downstream vendors, to their credit, have included this change in recent
OS releases by shipping OpenSSH packages that disable protocol 1 by
default and/or offering separate, non-default packages to enable it.

Debian takes the latter approach. Specifically, we have an
"openssh-client-ssh1" binary package that includes only scp1, ssh1, and
ssh-keygen1 binaries; we do not ship any server-side SSHv1 support. I
modelled this on Fedora's approach, which is basically the same aside
from a slightly different package name.

A number of our users are basically stuck needing to interoperate with
SSHv1-only servers that they can't update for one reason or another.
Obviously this is a pretty broken world, but maybe they're at least
behind a VPN or firewalled to the local network or something and at any
rate I'm rather glad that none of those things are directly my problem.

My plan for Debian (and thus Ubuntu etc.) is therefore that, once SSHv1
is entirely removed from OpenSSH, I will split out the
openssh-client-ssh1 binary package to be built from a separate source
package which will remain frozen at the last OpenSSH release that
supported SSHv1. As before, this will ship only scp1, ssh1, and
ssh-keygen1 binaries.

If I notice any fixes for client-side vulnerabilities that might affect
SSHv1, then I'll backport them on a best-effort basis, but I expect this
to be rare. The protocol is sufficiently broken anyway that I'm not
going to lose much sleep over it. I've had it suggested to me that I
should try to strip it down further (e.g. removing X forwarding
capability), but on the whole I think the chances of accidentally
breaking something as a result in something I don't myself use outweigh
the expected benefits.

Any comments on this? Feedback from the changes in 7.0 has convinced me
that Debian does need to keep shipping basic client-side support in some
form, but it can be very minimal and I'm happy to put whatever dire
warnings on it seem useful and appropriate.

Notwithstanding all this, the plan of removing all this obsolete code
from OpenSSH proper makes a lot of sense to me and I have no complaints
there.

[Nico Kadel-Garcia]

Post by Damien Miller

My plan for Debian (and thus Ubuntu etc.) is therefore that, once SSHv1
is entirely removed from OpenSSH, I will split out the
openssh-client-ssh1 binary package to be built from a separate source
package which will remain frozen at the last OpenSSH release that
supported SSHv1. As before, this will ship only scp1, ssh1, and
ssh-keygen1 binaries.
Notwithstanding all this, the plan of removing all this obsolete code
from OpenSSH proper makes a lot of sense to me and I have no complaints
there.

Your plan sounds emminently reasonable and I'll repeat my thanks
for your helping the transition by making separate -ssh1 packages.

It's also pretty funny to see a reversal of the old says when ssh-1
and ssh-2 were originally published, separately, and OpenSSH was able
to integrate the code bases to provide one set of binaries. Pulling
SSH-1 out of the server codebase is very sensible at this point. I'm
slightly concerned that people with older hardware, such as various
older firewalls, may find themselves with a problem.

[Michael Stone]

Pulling SSH-1 out of the server codebase is very sensible at this
point. I'm slightly concerned that people with older hardware, such as
various older firewalls, may find themselves with a problem.

If their security device is so old/unsupported that it only supports ssh1,
they probably already have problems--and using an old ssh1 client binary
probably isn't the biggest of them.

Mike Stone