On Fri, Apr 21, 2017 at 6:47 AM, navern <livingdeadzerg@xxxxxxxxx> wrote: > On 21.04.2017 08:49, Nico Kadel-Garcia wrote: >> >> On Thu, Apr 20, 2017 at 11:00 AM, Scott Neugroschl <scott_n@xxxxxxxxx> >> wrote: >>> >>> On Wed, Apr 19, 2017 at 1:02 PM, navern <livingdeadzerg@xxxxxxxxx> 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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
