Bug 3544

Summary:	Support CIDR notation for host pattern matching
Product:	Portable OpenSSH	Reporter:	bts
Component:	Miscellaneous	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	NEW ---
Severity:	enhancement	CC:	djm
Priority:	P5
Version:	9.1p1
Hardware:	All
OS:	All

Description bts 2023-02-27 14:33:21 AEDT

(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.)

Comment 1 Damien Miller 2023-03-02 12:07:31 AEDT

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.

Comment 2 bts 2023-03-02 14:07:56 AEDT

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....
)