bugzilla-daemon at mindrot.org
2023-Feb-27  03:33 UTC
[Bug 3544] New: Support CIDR notation for host pattern matching
https://bugzilla.mindrot.org/show_bug.cgi?id=3544
            Bug ID: 3544
           Summary: Support CIDR notation for host pattern matching
           Product: Portable OpenSSH
           Version: 9.1p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Miscellaneous
          Assignee: unassigned-bugs at mindrot.org
          Reporter: bts at square-r00t.net
(I considered putting this in ssh-keygen, but it's not just for
known_hosts.)
It would be fantastic if CIDR notation/matching for IPv4 and IPv6
address prefixes could be supported in "Host" matchers for ssh_config
and for the host matching in (ssh_)known_hosts.
I bumped into this the other day and assumed that because the
AllowUsers and AllowGroups scoping allows for CIDR prefixes, that the
same would be true for known_hosts.
This would be immensely beneficial for deploying system-wide
known_hosts across my fleet, namely because GitHub git server addresses
all use the same hostkeys (for sufficient reason, I suppose) but
encompass *many* different addresses/networks[0].
While I can certainly glob the addresses, globbing/wildcarding is a
particularly clumsy and perhaps outdated method of matching and, in
this case, leads to multiple host matchers (since one can't effectively
glob a /22, for instance, without splitting it into 4x /24's) when one
could suffice.
Using CIDR prefixes has the additional benefit of potentially faster
match processing, since comparison could be done via
bitshifting/bitwise operations et. al.
[0] https://api.github.com/meta (Refer to the "git" key.)
-- 
You are receiving this mail because:
You are watching the assignee of the bug.
bugzilla-daemon at mindrot.org
2023-Mar-02  01:07 UTC
[Bug 3544] Support CIDR notation for host pattern matching
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.
bugzilla-daemon at mindrot.org
2023-Mar-02  03:07 UTC
[Bug 3544] Support CIDR notation for host pattern matching
https://bugzilla.mindrot.org/show_bug.cgi?id=3544 --- Comment #2 from bts at square-r00t.net --- Thank you, Damien; that makes a lot of sense and I certainly can't imagine I'd be the first to suggest this. I too searched for something similar in bugzilla but couldn't find anything. I'm assuming the same/similar limitations apply to known_hosts key matching? Would it be possible to support some sort of prefix to these strings to indicate explicitly that they're e.g. a CIDR or address instead of hostname/DNS name and can thus skip globbing, translation, etc. and go to CIDR matching, etc.? e.g.: ip: cidr: ip6: cidr6: (thus, an ssh_config could have: Host ip:198.51.100.3 ... and a known_hosts could have: somehost,cidr:198.51.100.0/24 ssh-ed25519 AA.... ) -- 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.
bugzilla-daemon at mindrot.org
2023-Sep-14  11:39 UTC
[Bug 3544] Support CIDR notation for host pattern matching
https://bugzilla.mindrot.org/show_bug.cgi?id=3544
Celeste Liu <CoelacanthusHex at gmail.com> changed:
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |CoelacanthusHex at gmail.com
-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
Maybe Matching Threads
- CIDR address/masklen matching support for permitopen="host:port" restrictions?
- CIDR-matching in puppet manifests?
- [Bug 1009] Ability to use CIDR notation in IPV4/IPV6 named sets
- [Bug 1513] New: CIDR address/masklen matching support for permitopen=
- DO NOT REPLY [Bug 5851] New: Name lookup failures and CIDR regression