Include for sshd_config

[Nico Kadel-Garcia]

On Fri, Apr 21, 2017 at 6:47 AM, navern <livingdeadzerg at yandex.ru> wrote:
> On 21.04.2017 08:49, Nico Kadel-Garcia wrote:
>>
>> On Thu, Apr 20, 2017 at 11:00 AM, Scott Neugroschl <scott_n at xypro.com>
>> wrote:
>>>
>>> On Wed, Apr 19, 2017 at 1:02 PM, navern <livingdeadzerg at yandex.ru> wrote:
>>>
>>>> Is there any available tool with this for pre-evaluating the resulting
>>>> sshd_config for fatal errors? I'm not demanding: I'm thinking "that could be
>>>> really, really useful".
>>>
>>> What's wrong with "sshd -t"?
>>
>> Good reminder, thank you.
>>
>> I'm still slightly concerned about deploying a new, broken
>> configuration and being unable to get in to fix it. You'd have to
>> *stage* the deployment, first into a test environment against which
>> you can run "sshd -t", and then deploy them robustly and without
>> dangling bits to be sure that the test environment correlated well to
>> the production enviornment. But that's for fascist control in
>> environments where you can't get hands and eyes at the keyboard on the
>> local system, and especially if you're getting complex with your
>> "include" files.
>>
> Hello,
>
> Actually i can't see difference between "no include and typo brokes whole
> sshd server" and "include files and typo in include brokes whole sshd
> server". Other questions related more to configuration/system management.

It's a pretty similar problem. The danger is that if you put *other*
files into the mix, controlled by other tools, it becomes more
difficult to keep control of verification. If it's only one file, it's
easier to keep control of and check.

> With this include feature i manage as following:
> 1) main /etc/ssh/sshd_config is managed by ansible automatic configuration
> 2) include file is managed by python script on specific server(fills dynamic
> information)

How do you track and revert broken versions? Or do you have so much
trust in your configurations that you're sure they can't break things?

I ran into this headlong with the chef cookbook for openssh. It can
store configuration information among "roles", among "node" settings,
and among "environments", which it combines to assemble into the
sshd_config file published.  A subtle error in any one file where
settings are stored can propagate at configuration resetting time and
break the system, and become quite confusing to track down. The
flexibility provided is powerful and potentially quite useful. But it
comes with risks of debilitating errors.

My personal favorite for such errors in the chef cookbook are where
you accidentally set the same attribute multiple times with different
values, or especially if you provide multiple ruby hashes with the
same name and they get merged instead of replacing one with the other.