The `ssh_config` state supports generating `Host` sections, but it is
buried in the source. By default, options are simply dumped in the
configuration file; without any `Host` directive.

This patch hints (and, actually, encourages) users to use `Host`
sections by updating the pillar example to use the `Hosts` directive
with the `*` pattern.

Fix invalid require_in sshd_config for key states

Change the require_ins used by the key management states in the
config.sls to be conditional based on whether the sshd_config
is managed by the formula

Fixes #130

* Pillar openssh.known_hosts_salt_ssh

* Dropped ill-named file

* Fixed aliasing of host names

* Improved pillar.example

* Opt-in to include localhost

* pillar/known_hosts_salt_ssh: clear cache in run()

* Dropped forgotten debugging output

Add host keys from pillar to `ssh_known_hosts`

[openssh/config_ini] initial version of config_ini which uses ini state

fix iteritems for python3

closes #123

[FIX] When key is present override generating by any way

* drop default values (fixes #102)
* hmac-ripemd160 was dropped in 7.6

Add ConfigBanner to processed_options when handled.

Hostnames in known hosts

This prevents a verbatim version being added to end of file that will
cause the parsing to fail.

Fixed supporting multiline banner_string defined in the pillar.

CentOS 6: UsePrivilegeSeparation 'yes' (fixes #108)

UsePrivilegeSeparation 'sandbox'

This is was introduced in 5.9, and is default in 6.1.
https://www.openssh.com/txt/release-5.9
https://www.openssh.com/txt/release-6.1

Fixed key generation

- generate before running check_mk on the sshd_config
- set permissions on private key
- cope with empty keys

Create needed directory for UsePrivilegeSeparation option

Allow to configure SSH banner text in pillar

Allow to configure SSH banner text in pillar

Add optional {{ source }} to config files

OpenSSH's Match declarations are applied first-match-wins. However, we
can't safely define two Matches that might overlap unless we first sort
the keys, as Python (and Jinja) dicts don't guarantee the order of
dict keys,

We also won't scramble the match sequence every time the user adds,
removes or renames a match, and so we give the user clearer, more
concise diffs as when they apply changes.

Finally, we leave a comment on the Match line identifying where the
Match rule came from, to assist in troubleshooting.

Support complex compound matches in Match criteria. For example, be able
to match against multiple Users for a given Match, or be able to match
against address ranges. Or Groups. Or any combination thereof.

Support for matching users can take one of several different appearances
in pillar data:

sshd_config:
  matches:
    match_1:
      type:
        User: one_user
      options:
        ChrootDirectory: /ex/%u
    match_2:
      type:
        User:
          - jim
          - bob
          - sally
      options:
        ChrootDirectory: /ex/%u
    match_3:
      type:
        User:
          jim: ~
          bob: ~
          sally: ~
      options:
        ChrootDirectory: /ex/%u

Note the syntax of match_3. By using empty dicts for each user, we can
leverage Salt's pillar mergine. If we use simple lists, we cannot do
this; Salt can't merge simple lists, because it doesn't know what order
they ought to be in.