https://bugzilla.mindrot.org/show_bug.cgi?id=3544
Damien Miller <d...@mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |d...@mindrot.org --- Comment #1 from Damien Miller <d...@mindrot.org> --- I'm sure I had a bug for this, but I can't find it. The central problem (and reason this has not been implemented) is that configuration matching happens at the wrong time relative to name->address translation. The config is matches while the names are still names, and it's not trivial to convert them to addresses early because the names can change as a result of processing the config. A trivial example: Match address 10.10.10.10 # foo.example.com ForwardAgent yes Host foo.example.com Hostname bar.example.com If we performed address resolution before processing this configuration then we'd run the risk of incorrectly activating agent forwarding. There's a related problem for ProxyCommand/ProxyJump, where the destination address is likely to be unavailable or unreliable for common uses of these options. Finally, performing address-based configuration resolution necessarily puts DNS resolution into the trust path in a way that doesn't exist at present. An on-path adversary could effectively control which sections of a ssh_config were active by spoofing DNS responses and proxying TCP connections. This isn't a huge exposure, but it's subtle and hard to communicate. None of these concerns exist on the server side; there we know the connecting IP address as soon as the connection is established. This lets us do CIDR in AllowUsers, etc and Match without any hassle. If we were to implement Match address for ssh_config, we'd have to treat it similarly to what we do for address canonicalisation (CanonicalizeHostname), where we resolve everything else in the config on the first pass and then force a second pass where we no longer allow name changes. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. _______________________________________________ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs