Will validation fail if someone utilizes the sshd Include command in their extraConfig?

What if I'm running nixops and specify a ChrootDirectory directory that only exist on the target machine?

Does DenyGroups get validated and fail if the groups don't exist?

If sshd -t doesn't depend on the system environment too heavily this PR is fine, but generally these validation steps implemented this way concern me because they usually don't concretely validate anything but instead simply let you know that your configuration will probably work... sometimes... hopefully... as long as you didn't do anything too exotic.

I don't want to be sounding too negative on this topic, but when a few attempts at implementing validation on the httpd service ran into all sorts of problems I was very discouraged.

It's a shame there isn't some sort of stage between the building and activation of a generation that checks like this can run and then abort activation if the checks do not see succeed, leaving the user on the current generation without having cycled any services.

Will validation fail if someone utilizes the sshd Include command in their extraConfig?

Unless I'm missing something, this won't break validation (tested with sshd from OpenSSH_7.9p1 on NixOS 19.03).

Does DenyGroups get validated and fail if the groups don't exist?

Same here. It seems as no content is validated, however syntax and the specified options.

I don't want to be sounding too negative on this topic, but when a few attempts at implementing validation on the httpd service ran into all sorts of problems I was very discouraged.

IIRC this is also implemented for prometheus and I actually liked it while using that module.
Can you please send me a link to the discussion? I'd be very interested in learning which problems were faced there :)

It's a shame there isn't some sort of stage between the building and activation of a generation that checks like this can run and then abort activation if the checks do not see succeed, leaving the user on the current generation without having cycled any services.

That's actually an interesting idea for the "Future work" section of RFC#42 which actually recommends the use of config validation tools if available/possible.

@Ma27 the history of this problem actually goes back years...

• a recent discussion including myself lamenting over declarative apache configs here
• which spawned nixos/httpd: always test the generated configuration #58033
• nginx: Check syntax also at nix evaluation time #35395 (comment)

There are more issues/prs which discuss this, but the list above is all I could find with minimal effort.

So unless I'm missing something, the main issues with config validation at build time are (1) issues with cross-builds and (2) false-positives when having a complex config that only works in a certain environment.

(1) should be solvable by using nativeBuildInputs in the derivation that validates the config (I'll change that later that day)
(2) doesn't seem to be a problem according to my test results. To quote sshd(8):

       -T     Extended test mode.  Check the validity of the configuration file, output  the  effective
              configuration  to stdout and then exit.  Optionally, Match rules may be applied by speci‐
              fying the connection parameters using one or more -C options.

       -t     Test mode.  Only check the validity of the configuration file and  sanity  of  the  keys.
              This is useful for updating sshd reliably as configuration options may change

If I understand thsi correctly, my approach simply checks the syntax and the used configuration keys.

Does this look ok to you? Or am I missing something?

@Ma27 The apacheHttpd configuration validation validates the entire environment referenced by the configuration file, not merely syntax. In the case that a program validates environment referenced by a configuration file this approach can't work the way things are because configuration files might reference users that don't exist yet, or files that are on nixops targets but not the nixops host.

It looks like you have confirmed that the ssh configuration validation doesn't actually validate the environment at all, so in this case I'm happy that this PR is good to go 👍