Often, configuration files work like this:
- global settings are at the top
- detailed settings are further on, overwriting global settings
Not for ssh_config though, so I was right writing I should read more on it in Good read for starting to intermediate ssh users is “SSH Essentials: Working with SSH Servers, Clients, and Keys | DigitalOcean” and pointers to more advanced reading material.
So here is how ssh_config does it as per man page at [WayBack] ssh_config(5) – OpenBSD manual pages and [WayBack] ssh_config — OpenSSH SSH client configuration files at Linux.org:
For each parameter, the first obtained value will be used. The configuration files contain sections separated
by “Host” specifications, and that section is only applied for hosts that match one of the patterns given in the
specification. The matched host name is the one given on the command line.
Since the first obtained value for each parameter is used, more host-specific declarations should be given near
the beginning of the file, and general defaults at the end.
This means a section Host * needs to come at the end.
I got that wrong and it took me the better half of a morning to figure out the cause of a connection problem ending in this:
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: remaining preferred:
debug1: No more authentication methods to try.
Somehow, the identity file was never used to try public key authentication at all because of the ssh_config order in ~/.ssh/config.
I’m not the only one confused, as during the search for the cause with “remaining preferred” “No more authentication methods to try.”:
Maybe now I should step up from manually editing the ssh_config file and use [WayBack] GitHub – moul/advanced-ssh-config: make your ssh client smarter to generate it for me.
–jeroen
The Wiert Corner - irregular stream of stuff 