[Bug 3419] New: regular expression patterns in Host directive

[bugzilla-daemon at mindrot.org]

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

            Bug ID: 3419
           Summary: regular expression patterns in Host directive
           Product: Portable OpenSSH
           Version: v9.0p1
          Hardware: Other
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Miscellaneous
          Assignee: unassigned-bugs at mindrot.org
          Reporter: calestyo at scientia.org

Hey.

One thing that could be really nice was, the Host directive (not sure
whether it would make sense for Match, too) would allow to match not
only the current patterns (which basically have "just" '*', '?', "[…]"
and '!') but general regular expressions.

The idea is that one is able to more thoroughly specify hostnames, e.g.
right now, in order to match:
server1.example.org
server2.example.org
server3.example.org
one can do:
a) server*.example.org
b) server?.example.org
c) server[1-3].example.org

(a) and (b) are not really exact (as they'd also match e.g.
serverX.example.org). (c) is difficult if one has more digits (servers
1-45) and really wants to match only those.

The above is still a very simple example of course, but with regular
expressions one could do much more nice things like matching:
(www\.)?[^.]+\.(intranet|public)\.example\.(com|biz)

Or (at least if PCRE were chosen as RE language) one could do
exclusions (i.e. all but a certain pattern).


So the first motivation for such feature is "simply" to better select
the actually desired hostnames only (which * and ? may not always help
with).


And I guess that level is what this enhancement idea is about.


Possible future ideas:

However, this could be made even much more useful, if one would allow
to use the matched subexpressions via back-references in the
sub-directives of a given Host block.
IIRC Apache httpd, can do such things in its
<(Location|Directory|File)Match> blocks.

I think of use-cases like:
Host ^[^.]+\.(intranet|public)\.example\.com$
     Identity ~/.ssh/example.com_\1_id_rsa

where different keys are used with different groups of hosts.

The above is obviously something, which one could do also now (just
with a bit more configuration lines.


One could however think to even further extend syntax:

We at the university run many servers for the LHC Computing Grid.
These are all named like server<n>.example.org
We buy new ones every 2-3 years, and these are then all the same (so
.e.g. n = 1 - 34 are one model and 35-53 another or so)

These have service processors (like HP's ILO or Dell's iDrac) whose SSH
we use for serial console access... and typically their SSH is not so
well maintained and after a while upgrades stop, so they don't support
modern algorithms (e.g. just RSA keys, but not ED25519) or need things
like:
        KexAlgorithms                  
+diffie-hellman-group-exchange-sha256
        HostkeyAlgorithms               +ssh-rsa
        PubkeyAcceptedAlgorithms        +ssh-rsa


If one would now have something like an <If> directive that matches
TOKENS or the above back-references one could do things like:

Host ^server(\d+)\.service\.example\.com$
     ProxyJump ...
     User ...
     If %1 >= 1 AND %1 <= 34
     {
        KexAlgorithms                  
+diffie-hellman-group-exchange-sha256
        HostkeyAlgorithms               +ssh-rsa
        PubkeyAcceptedAlgorithms        +ssh-rsa
     }
     If %1 >= 35 AND %1 <= 52
     {
         # possible other non default settings
     }
The backref would be handled like a TOKEN.

Obviously, one would then need a powerful If directive with many
operators, perhaps again with regexp string matching and perhaps also
with conversion of the matched strings to integers... or operators like
"in".


Not saying that this would really be worth all the (considerable)
effort... it would be just something to keep in mind for possible
future developments.


Cheers,
Chris.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.