[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#806962: No supported cipher blowfish breaks systems



On Thu, Dec 03, 2015 at 06:15:44PM +0100, Klaus Ethgen wrote:
> Am Do den  3. Dez 2015 um 17:57 schrieb Colin Watson:
> > This is true, although I rather suspect that it was in fact an
> > ineffective configuration in the first place (i.e. blowfish was never in
> > fact selected).  You could easily confirm this by downgrading and using
> > "ssh -vvv" with your old configuration; in fact, I encourage you to do
> > so and post the output here.
> 
> It was as I configured "Cipher" _and_ "Chiphers". While Ciphers has
> blowfish-cbc in the first place, Chiper was expecting blowfish without
> -cbc.

Aha.

> > You can always override global ssh_config at a per-user level.  Your
> > report is about accessing other systems from an upgraded ssh client,
> > which means that it is irrelevant whether the remote side is root with
> > pubkey authentication only or an ordinary user account.
> 
> Nope, not that. I have it overwritten in my local .ssh/config file but
> it still complains about the error in global file.
> 
> Well, I access the local server from a local client on a system that
> only allows passwordless root access vial localhost ssh.

Oh, right, got it.  In that case I suggest using "ssh -F ~/.ssh/config",
since that will cause it to not even try to parse /etc/ssh/ssh_config;
you can then use that to make the system's /etc/ssh/ssh_config
consistent with the upgraded client.  Does that help?

> >     - Support for the legacy SSH version 1 protocol is disabled by default
> >       at compile time.
>       - Some (legacy or not) cipher algorithms are not legal anymore.
> 	Check your configuration before you upgrade.
> 
> I do not know if it makes sense to enlist that explicitly. I would as it
> makes it easier for people to find it in there config.

I probably won't amend debian/changelog, but I'll include something like
that in NEWS.Debian.

> > particularly since I do in fact strongly agree with
> > disabling protocol 1!
> 
> Oh, you find "Protocol 2" in all my configurations. However, on client
> side I still need to have protocol 1 as many embedded systems like
> routers only have ssh1 support.

Yes, I'm not sure of the right long-term approach for that.  I rather
suspect that OpenSSH upstream is hoping to act as a forcing function to
get those systems to get their act together with long-overdue upgrades,
which seems laudable but I don't know how successful it will be.  As far
as Debian is concerned, it may make sense to add a separate client-only
binary package for those that really really need it, but I'll see how
things look over time; it may be that protocol 1 support is entirely
removed from the OpenSSH source tree in the near future, which would
make it difficult to support such a thing longer-term.

-- 
Colin Watson                                       [cjwatson@debian.org]


Reply to: