Hmm, don't those as-its-parsed semantics already apply to something like
Match exec though? Based on a quick test it looks like you get different
effects for
Match exec "[ %r = foo ]"
UserKnownHostsFile ~/bar
Match all
User foo
versus
Match all
User foo
Match exec "[ %r = foo ]"
UserKnownHostsFile ~/bar
As far as I can tell there aren't call-outs about those alternate token
semantics of match exec (though maybe there should be?). But at worst it
seems like there's _some_ precedent for the semantics of applying tokens as
you parse?
On Sat, Jan 23, 2021 at 2:56 PM Darren Tucker <dtucker@xxxxxxxxxxx> wrote:
> On Sun, 24 Jan 2021 at 07:57, Ian Haken <ihaken@xxxxxxxxxxx> wrote:
> > I've got a feature request which is (hopefully?) straightforward, which
> is
> > that we'd like to be able to use tokens (%n specifically for the original
> > remote hostname) as a token on the Include directive.
>
> Unfortunately it's not straightforward.
>
> Include directives are read and processed as the config file is parsed
> (readconf.c, look for "case oInclude"). Percent-token expansion
> happens after the config is fully parsed, immediately before it's used
> (ssh.c, look for the percent_dollar_expand calls). It would probably
> be possible to perform some kind of expansion when Include is parsed,
> but it would have different semantics compared to all of the other
> expansions, eg
>
> UserKnownHostsFile %r/bar
> User foo
>
> does expand UserKnownHostsFile, to foo/bar but
>
> Include %r/bar
> User foo
>
> would not.
>
> --
> Darren Tucker (dtucker at dtucker.net)
> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
> Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
