[Bug 3544] Support CIDR notation for host pattern matching

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3544

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at 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.