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)
On Tue, May 03, 2016 at 10:33:29PM +1000, Damien Miller wrote:> 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. -- Colin Watson [cjwatson at debian.org]
On Tue, 3 May 2016, Colin Watson wrote:> 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