wishlist: provide ssh::server::config_entry

[arnd]

Ssh::Server::Custom_config works but is a little bit fragile.
(User needs to make sure, that a config option doesnt gets set twice, that content contains a newline etc.)

Example:

ssh::server::custom_config{ 'set_the_authorzied_key_command':
  content => "AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys\n"
}

I propose to introduce a define ssh::server::config_entry like:

ssh::server::custom_config{ 'AuthorizedKeysCommand':
  value => "/usr/bin/sss_ssh_authorizedkeys"
}

[aptituz]

We already talked about this one in private, just commenting for the purpose of documenting it:

AFAICT your problem is two-fold, with one easy solution and one not so easy solution:

• Adding a wrong custom_config can break access to the system, since there is currently no validation in place for the sshd_config file. Since I'm currently dropping support for puppet versions prior 3 I'll address this first by adding a validate_cmd setting, calling sshd -t.
• Support for key-value-based configuration

Note that the custom_config define is a compromise between the previous extreme of a monolithic template and what would be optimal in my opinion: a custom type for sshd config entries.

Unfortunately the latter is non-trivial, because it would need to support match-blocks in existing configurations in a way that existing configurations at least do not break. I currently do not know how to implement that with - say - the parsedfile provider (which would perfectly fit the rest of the configuration).

What you proposed is certainly possible, although it tackles only some and not all of the problems with the current approach (e.g. conflict potential with the settings in the base template). I'm more then willing to accept a pull request for a ssh::server::config_entry define as an abstraction layer above custom_config, but currently not willing to implement it myself, since I'm still thinking about how a true type could be achieved.