Deprecated sshd options

[learnitall]

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:

$ journalctl -u sshd
Jul 22 12:51:24  systemd[1]: Starting OpenSSH server daemon...
Jul 22 12:51:24  sshd[12040]: /etc/ssh/sshd_config line 23: Deprecated option UsePrivilegeSeparation
Jul 22 12:51:24  sshd[12040]: /etc/ssh/sshd_config line 26: Deprecated option KeyRegenerationInterval
Jul 22 12:51:24  sshd[12040]: /etc/ssh/sshd_config line 27: Deprecated option ServerKeyBits
Jul 22 12:51:24  sshd[12040]: /etc/ssh/sshd_config line 45: Deprecated option RSAAuthentication
Jul 22 12:51:24  sshd[12040]: /etc/ssh/sshd_config line 54: Deprecated option RhostsRSAAuthentication
Jul 22 12:51:24  sshd[12040]: Could not load host key: /etc/ssh/ssh_host_dsa_key
Jul 22 12:51:24  sshd[12040]: Server listening on 0.0.0.0 port 22.
Jul 22 12:51:24  sshd[12040]: Server listening on :: port 22.
Jul 22 12:51:24  systemd[1]: Started OpenSSH server daemon.

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

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

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

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

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

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

[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!

[alxwr]

at long last: #117

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