[Bug 3419] regular expression patterns in Host directive

[bugzilla-daemon at mindrot.org]

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

--- Comment #2 from Christoph Anton Mitterer <calestyo at scientia.org> ---
Nice, though the syntax is a bit ugly ;-)

But AFAIU, this would only work if the user's shell is bash, as it uses
the non-standard <<<, right?


And it gives some ugly errors, if the user accidentally has a ' in the
hostname.
In principle one could even think that this may cause accidental
execution an intended remote command, locally:

It's a bit constructed of curse, but consider something lile:
intended:
ssh -G  "foo.public.example.com" "'; echo 'foo' >&2'" | awk
'$1=="hostname"'

written by accident:
ssh -G  "foo.public.example.com'; echo 'foo' >&2'" | awk
'$1=="hostname"'
that actually prints:
foo
hostname matched

Now replace echo 'foo' with 'rm -rf /'.

But of course it's clear, that the same could just happen without using
the Match-exec at all... so it's not really an issue I think.




With %h, AFAIU, one really get's the same behaviour as with Host
<pattern>, i.e. after any substitutions via the Hostname or
CanonicalizeHostname options, right?
Could that be added to the description of %h? It already says for %n
that it's the one from the command line.

I could provide a patch if it helps you.


Since you've left the issue open,... do you still consider this? Or is
the Match+exec solution the way to go?
Cause if the latter, it would be nice if one could perhaps add that as
an example somewhere in the config.
Ideally with non-bash specific code, I guess printf '%s' '%s' | egrep
... should do the job, too?!

One subtle remaining issue is perhaps, that this solution means that
the values of %-escapes appear in the process list.
I mean there is non like %p with p being the password, but it might
still be undesired by a user that others can see e.g. the true %h,
which may have been obfuscated by using a fake name on the command
line, and having ssh_config substitute that to the real one.
But again, only a very subtle thing, as usually there are other means
to find out that for another user.




Cheers,
Chris.

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