On Wed, 2015-01-07 at 15:25 +0000, Matthew Vernon wrote:
> Christoph Anton Mitterer <calestyo@scientia.net> writes:
>
> > On Tue, 2015-01-06 at 18:52 +0200, Vasil Kolev wrote:
> > > - get openssh to generate 4096-bit RSA keys by default;
> > ... and disable DSA and RSA1 keys, which is possible if you name all
> > other "default" key explicitly in the config, like:
> > sshd_config:
> > HostKey /etc/ssh/ssh_host_ed25519_key
> > HostKey /etc/ssh/ssh_host_ecdsa_key
> > HostKey /etc/ssh/ssh_host_rsa_key
> > #Note: SSH Version 2 DSA host keys are implicitly disabled.
> > ##HostKey /etc/ssh/ssh_host_dsa_key
> > #Note: SSH Version 1 RSA host keys are implicitly disabled.
> > ##HostKey /etc/ssh/ssh_host_key
>
> The problem with this approach is that you won't get any new keys onto
> your system in future openSSH versions that support them. So if we did
> this in Debian, then everyone would have to remember to update that
> list themselves on subsequent upgrades.
Sure... I definitely wouldn't want to touch existing configs
automatically (unless they're equal to Debian's default config).
Apart from that, people should probably start to learn that SSH is a
complex service just like httpd or anything else,... and that for
properly maintaining it is not enough to install upgrades without
looking at the changelogs, configs, etc.
So I think that this "everyone would have to remember that..." should
anyway be the case:
- either upstream chooses to always change to hardened defaults
=> than people need to look at their stuff, because they might need to
manually enable less secure things for interoperability with older
clients/servers
- or upstream doesn't choose hardened defaults
=> then people should need to look at their stuff because less secure
or insecure may be allowed
What ever you do.. people have a duty to properly maintain their
stuff,... even for "simple" things like SSH.
And in general I prefer that things are secure per default, and only
those people have to suffer which don't do their homework.
> And, we'd rather use upstream config where possible, I think.
Sure, as I mention in in #74793)...but what if they don't?
Cheers,
Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature