added possibility to configure server version and client version
with pillar example

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.