[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Config file parsing order
[Thread Prev] | [Thread Next]
- Subject: Config file parsing order
- From: Tilo Eckert <tilo.eckert@xxxxxxx>
- Reply-to: libssh@xxxxxxxxxx
- Date: Fri, 14 Feb 2020 12:59:13 +0100
- To: libssh@xxxxxxxxxx
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
Re: Config file parsing order | Anderson Sasaki <ansasaki@xxxxxxxxxx> |