[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Config file parsing order


Hi everyone,

we are currently facing an issue with the order in which options from
the OpenSSH config files are applied.

When setting up a connection, we call ssh_options_set() for all options
we want to set, followed by ssh_connect(). Commit 89a8a6fc introduced
automatic loading of user-specific and system-wide OpenSSH config files
if no config file has been loaded explicitly. This overrides options
previously set with ssh_options_set() if they also appear in one of the
config files as mentioned in the commit message.

There are multiple problems with this behavior:

1) It is counter-intuitive. Options set explicitly should override
options set in automatically loaded config files. The default global
OpenSSH config file is intended to contain reasonable defaults which may
be overridden by the user-specific config file or via command line.
From OpenSSH docs:
> ssh(1) obtains configuration data from the following sources in the following order:
>       1.   command-line options
>       2.   user's configuration file (~/.ssh/config)
>       3.   system-wide configuration file (/etc/ssh/ssh_config)
> For each parameter, the first obtained value will be used.

Imo, that is how it should work in libssh, too.

2) Libssh implements the exact opposite order. This leads to conflicts
if the user uses the OpenSSH client and a libssh-based client on the
same machine/account. For example, if the user configures his
non-default known_hosts path in ~/.ssh/config to avoid passing it to the
OpenSSH CLI every time, there is no way to override this with
ssh_options_set() if the user wants to use a different known_hosts file
with libssh. The user of the libssh-based client would need to create a
new config file that we have to load with ssh_options_parse_config()
before connecting.

3) We could call ssh_options_parse_config(session, NULL) before setting
our own options to work around it, but the user and system-wide config
files would still be loaded in the wrong order, with system-wide config
taking top priority.

4) There is no documentation about the overriding behavior of the
ssh_connect() function.

TL;DR
Is it intentional that libssh options priority is the exact opposite of
what OpenSSH does? If yes, why?
Wouldn't it be more reasonable if options from autoloaded config files
are only applied if not already set?

Regards,
Tilo Eckert

Follow-Ups:
Re: Config file parsing orderAnderson Sasaki <ansasaki@xxxxxxxxxx>
Archive administrator: postmaster@lists.cynapses.org