Deprecated sshd options

[saltstack-formulas]

Deprecated sshd options

[alxwr]

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

[aboe76]

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

[alxwr]

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

• No pillar data => empty config file => a.k.a. let OpenSSH decide what's best (for the installed version)
• i.e. Port 2222 in pillar data => only Port 2222 in config file => let OpenSSH handle all other settings

Currently there are three sources of effective config used by OpenSSH:

• OpenSSH defaults
• This formula's defaults. (Where it seems we're doing a sub-optimal job.)
• The explicit will of the admin a.k.a. Pillar

When we cease setting defaults this is reduced to:

• OpenSSH defaults
• The explicit will of the admin a.k.a. Pillar

=> 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]

at long last: #117

[aboe76]

@DevelopForLizardz and @alxwr we need to make sure that the options change are indeed the defaults sshd will use if commented...

[zatricky]

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.

[alxwr]

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

[0xf10e]

@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…

[aboe76]

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

[javierbertoli]

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:

1. When you use the formula by default (say, just including formula in your states), configuration is not attempted at all: the formula doesn't touch the configuration files and they are left as provided by the package/distro.
2. If you decide to modify configuration, explicitely stated in a pillar parameter (like manage_config), a pillar parameter set with configuration values (like config) or a state file explicitely included (like config.sls), etc., the formula picks a set of sane default values (These default values can be set in the different yaml files for defaults, os, osfamily, etc.), applies your local (pillar) modifications on top of those and that config is deployed.

This approach has these advantages:

1. Allows you to adopt a formula and manage an app you already have installed, knowing that your current configuration will be left as is by default.
2. Once you're comfortable with the formula managing the packages/services correctly, you can 'fine tune' the configuration, to match the current one you have or to modify it.
3. These two points let you adopt new formulas in your current environment, with a fair certainty that it won't break things on first run.

[learnitall]

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.

[aboe76]

@alxwr I don't see a problem with it, I'm happy to test your PR.

[learnitall]

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.

[0xf10e]

👍 @alxwr

[alxwr]

Oh man, time's running fast. Sry, got loads of other work to do. Still eager to implement this!

[zatricky]

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.