Closed learnitall closed 6 years ago
@DevelopForLizardz We could make the deprecated variables commented by default instead of uncommented.
{{ option('UsePrivilegeSeparation', 'sandbox') }}
{{ option('KeyRegenerationInterval', 3600) }}
{{ option('ServerKeyBits', 1024) }}
{{ option('RSAAuthentication', 'yes') }}
{{ option('RhostsRSAAuthentication', 'no') }}
Then only when you set them in pillar explicitly or override them with a different value will they be used in sshd_config file.
@DevelopForLizardz and @alxwr we need to make sure that the options change are indeed the defaults sshd will use if commented...
man 5 sshd_config
does list defaults for all options.
Though its not a big issue, I found it odd that values set to the same as default aren't commented to begin with. Perhaps you might consider that for a future strategy.
@DevelopForLizardz @aboe76 IMHO the main problem is the question „Which defaults?“. They change from one OpenSSH version to another.
So I'd start by reliably determining the actual OpenSSH version. Either we get this via map.jinja
or we add a grain. (I've got one lying around here.)
Given we know the exact OpenSSH version we can then decide on which deprecated directives to remove.
Just in case I missed something: Is there a way to add Grains to Salt formulas (just like Facts to Puppet modules)?
Otherwise I suggest we enrich map.jinja
with (default) OpenSSH versions (which would be my favorite).
@zatricky as @alxwr just said the defaults change through the versions.
@alxwr on non-rolling-release platforms with
pkgs for OpenSSH pkg.version_compare
could be used to check if the installed pkg
has the default version for this osfinger
.
I think adding the defaults for all the versions
to map.jinja
would make this file pretty big.
I'd rather have this data somewhere like
defaults.yaml
or maybe version_defaults.jinja
…
I think adding the defaults for all the versions to
map.jinja
would make this file pretty big.
Totally agreed. I was rather talking about the mechanism (defaults vs. grains). Frankly the concept of documenting the entire history of OpenSSH config differences in map.jinja
and *.yaml
seems to be IMHO overkill.
I propose another solution involving less maintenance cost: drop option_default_uncommented
. Just assume the OpenSSH defaults are sane and secure for the installed version. (Which they usually are.) Let everything else be done by the maintainer of the Pillar.
We can't reliably know the exact version of OpenSSH. Therefore we can't decide which directives to include or exclude or which values are the correct defaults. (And even if we could: what if we get it wrong?) Let default directives and values be handled by OpenSSH and/or Pillar. :-)
@alxwr I think you are right with your proposed solution to assume OpenSSH defaults to be sane and secure and only uncomment those options which are in Pillar. This makes it clearer for everyone that uses this formula to set exceptions on the defaults in pillar, and leave everything else the same.
My 2c:
Something I don't see much in formulas (that worked really well for me when I used to write puppet modules), and that goes in the lines of @alxwr proposal, is the following logic regarding configurations:
This approach has these advantages:
I think that @alxwr and @javierbertoli have the right idea. I could be misunderstanding, but wouldn't picking default values that local pillar modifications can then be applied to require a large map.jinja
file as @alxwr was talking about? If so, then maybe applying the local modifications on top of the configuration file itself could address this. This way we wouldn't have to try picking defaults for each OpenSSH version or platform.
@javierbertoli I agree, but don't we already have that (in this formula)? init.sls
does not include config.sls
.
local modifications on top of the configuration file itself
@DevelopForLizardz, currently we're replacing whatever config there was before with defaults+Pillar. That's the most stable (because simple) way of handling config files. I would not want to change this.
When I say "defaults" I don't mean the stuff distro X puts in the config file, but rather the settings OpenSSH uses when given an empty config file.
The idea is this: Don't pick any defaults at all, let OpenSSH do this.
Port 2222
in pillar data => only Port 2222
in config file => let OpenSSH handle all other settingsCurrently there are three sources of effective config used by OpenSSH:
When we cease setting defaults this is reduced to:
=> no initial config needed
=> no unexpected effects for the admin
=> no need to maintain a huge map.jinja
and/or *.yaml
But: I strongly suggest showing secure settings (Ciphers, KexAlgos, ...) in pillar.example
.
Does anybody see a problem with this approach? If not I'd be happy to submit a PR as soon as my time allows for it.
@alxwr I don't see a problem with it, I'm happy to test your PR.
It seems I didn't grasp your proposal very well the first time @alxwr, so I appreciate your clarification- thank you. I think I got mixed up when @javierbertoli commented about formulas picking default values when pillar data for a config is specified. My apologies. Anyways though, I'm on the same page as @aboe76.
:+1: @alxwr
Oh man, time's running fast. Sry, got loads of other work to do. Still eager to implement this!
at long last: #117
From changelog at https://www.openssh.com/releasenotes.html
ssh(1)/sshd(8): remove support for the hmac-ripemd160 MAC.
Highlighting how this change to defaults-handling is essential, I just updated a bleeding-edge host (ArchLinux) to openssh 7.6 and found sshd refused to start.
Most changes are because SSH protocol v1 support is now "deleted" - but these mostly result in warnings, not errors. This particular MAC change does result in an error, causing that sshd refuses to start.
I am using this formula to manage openssh in small home environment, and while applying some states I came across deprecation warnings in the sshd logs of a Fedora 26 minion:
(I don't have the deprecated options specified in Pillar.)
I did a little research and it seems to be that these options were removed from the sshd_config file in recent versions of OpenSSH 7, in preparation of removing support for SSH protocol 1. This makes sense as Fedora 26 uses version 7.5 of OpenSSH and I don't get these warnings when running the state on Centos 7.3 systems which are using version 6.6 of OpenSSH.
This isn't a major issue as nothing is broken of course, but I thought it might be a good idea to bring it up.