Re: Server configuration

[Jakub Jelen <jjelen@xxxxxxxxxx>]

Hello,
I added few comments to the PR.

On Thu, 2019-03-07 at 12:26 -0500, Anderson Sasaki wrote:
> Hello all,
> 
> I'm currently implementing support to set the server (bind) options
> through configuration files. The current state can be followed in the
> PR I've opened in gitlab [0].
> 
> During the implementation, I realized some expected behaviors are not
> clearly defined (or documented), being the main issue related with
> the precedence of the options. I followed the implementation of the
> client side (session) options configuration as close as I could.

When we try to follow what is in OpenSSH, the first met option is
always used and is not overwritten by any following option.

But unlike in the client, which config is usually tweaked by the users,
the server should really load only the default configuration file or
the one provided by the application developer through the API
(ssh_bind_config_parse_file). I do not think we should need to parse
more configuration files by default.

> So the questions are:
>  * Currently if one option is set by one configuration file, the next
> configuration file can't set it again. Is this the expected behavior
> from the user point of view?
>    - note: This is used to not override user options with the global
default options. The user options are parsed and then the global
> options are parsed. The ones set before are kept. In my opinion it
> would be better to reverse the logic and parse the global options
> before and override them with the user options as he or she prefers.

This is what is expected by users from OpenSSH configuration files. See
manual page for ssh_config, which describes this behavior. It might not
have been the best decision in the past, but with libssh we need to try
to be compatible with configuration files so the users can see
consistent behavior of the clients.

For the server, we probably have more freedom, but keeping it same
would make our life easier and documentation simpler.

>  * If the user sets one option manually (through ssh_options_set()),
> but the option is defined in the global configuration file, the
> global setting will overwrite the user setting. Is this expected?
>    - note: This happens because setting options manually does not set
> the bool in the session.options_seen table. When the user calls
> ssh_connect(), the global configuration will be parsed, overwriting
> the options set manually by the user. In my opinion, the manually set
> options should be kept.

This could be an issue if application developer setting some option
through ssh_options_set() really needs it to come through. But I can
not come up with a use case where it would be strictly needed, except
some very specific ones, which could be addressed by disabling
configuration parsing.

Again, for the server, it might make more sense, especially when the
config will provide ListenAddress and Port, but libssh application will
really need different one. I am wondering if these two options make
sense to parse from configuration at all and we should not limit the
scope to the cryptographic mechanisms only.

> Resuming, the best for me would be:
>  - The global configuration is parsed before any other
>  - Settings done manually by the user (either by calling
> ssh_options_set() or ssh_options_parse_config()) take precedence over
> the global settings, being kept the last set.
>  - Global settings done automatically (e.g. the one called in
> ssh_connect()) don't override manually set options
> 
> Other than this, it would be better to be able to define the default
> location of the global configuration file in build (cmake) time,
> instead of having it hardcoded.

Using the server config path as a build time option might make sense,
defaulting to sshd_config or something else for crypto policy in
Fedora.

Regards,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.