On Thu, 27 Aug 2015, Bostjan Skufca wrote:> Are you connecting by specifying "ssh HOSTNAME" instead of "ssh IP.IP.IP.IP"? > > If this is the case, then "Host 192.168.*.*" line never matches when > you think it should. > > From ssh_config manpage: > "The host is the hostname argument given on the command line (i.e. the > name is not converted to a canonicalized host name before matching)."Yeah, it's unfortunately quite difficult to implement address matching in ~/.ssh/config because of the interplay of Host matching, Hostname directives, hostname canonicalisation*, proxy commands, hosts having multiple addresses, IPv4/IPv6 and when the addresses are actually resolved and available to the parser. I've not figured out a clean way to do it that isn't also complex and probably fragile to implement. -d * that was my contribution to the problem :/
On 27 August 2015 at 05:01, Damien Miller <djm at mindrot.org> wrote:> Yeah, it's unfortunately quite difficult to implement address matching > in ~/.ssh/config because of the interplay of Host matching, Hostname > directives, hostname canonicalisation*, proxy commands, hosts having > multiple addresses, IPv4/IPv6 and when the addresses are actually > resolved and available to the parser. > > I've not figured out a clean way to do it that isn't also complex and > probably fragile to implement.If we disregard the "complex and probably fragile" part, what is the "clean way" you are talking about? Do you have some sort of RFC written down somewhere? b.
On Fri, Aug 28, 2015 at 8:48 AM, Bostjan Skufca <bostjan at a2o.si> wrote:> On 27 August 2015 at 05:01, Damien Miller <djm at mindrot.org> wrote: >> Yeah, it's unfortunately quite difficult to implement address matching >> in ~/.ssh/config because of the interplay of Host matching, Hostname >> directives, hostname canonicalisation*, proxy commands, hosts having >> multiple addresses, IPv4/IPv6 and when the addresses are actually >> resolved and available to the parser. >> >> I've not figured out a clean way to do it that isn't also complex and >> probably fragile to implement. > > If we disregard the "complex and probably fragile" part, what is the > "clean way" you are talking about? > Do you have some sort of RFC written down somewhere?The interplays between DNS and multiple formats for the same target SSH server makes such an RFC a nightmare in outsmarting all the local settings. In complex environments, I'm afraid that "known_hosts" is often an active detriment to stable operation, especially because there is *no* published tool for "scrub the old rejected line and accept the new one*. It's most clear when a new server on the same IP address replaces an old host but uses new SSH host keys. In environments where critical server hostnames and IP addresses are not tied to consistent SSH keys, I'm afraid there is little choice but to discard the use of known_hosts.