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

Bug#806962: No supported cipher blowfish breaks systems

Hash: SHA512

Am Do den  3. Dez 2015 um 17:57 schrieb Colin Watson:
> On Thu, Dec 03, 2015 at 05:49:19PM +0100, Klaus Ethgen wrote:
> > Am Do den  3. Dez 2015 um 17:36 schrieb Colin Watson:
> > > Ah, so this is not quite accurate.  "blowfish" is an SSH1-only cipher
> > > name, and as far as I can tell was never effective for SSH2.  OpenSSH
> > > 7.0 disables protocol 1, which is perhaps why you're seeing "blowfish"
> > > no longer doing anything.
> > 
> > That might be, but configurations regarding that was still possible.
> > With current systems that configuration is an error and ssh fails to
> > work at all.
> 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.

> > > But of course you can make this change after upgrade - it's client-side.
> > 
> > And if you have ssh-with-key-only root on some systems, it is very hard
> > to change that setting in global ssh_config.
> 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.

> > Why do you bristle that much against documenting that in NEWS.debian.gz
> > where it should be!? Currently it is not even mentioned in changelog.
> It's right up top, once the problem is correctly understood:


>     - 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.

> > > and if you are going to make this kind of
> > > choice then you need to own the fact that you'll have to keep it up to
> > > date, or maintain your own fork of OpenSSH.  Debian will stick with
> > > mainline upstream choices here.
> > 
> > Yea, I still have to have my own debian package of openssh due the fact
> > that debian is _not_ sticking to mainline upstream choices and have some
> > questionable patches in the package. Patches that upstream refused for
> > security reasons. It would be not really more work to enable that too
> > here.
> Some of those are historical mistakes that I'm stuck with, and some are
> ones I'm gradually working to move away from.  That doesn't mean it's OK
> to expand the list,

I will not go further into that point. There was enough discussion about
that on the ML at the time. I even seen with positive surprise that you
already droped one of that questionable patches.

> 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.

- -- 
Klaus Ethgen                              http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen <Klaus@Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
Version: GnuPG v1


Reply to: