https://bugzilla.mindrot.org/show_bug.cgi?id=3419
--- Comment #2 from Christoph Anton Mitterer <calestyo@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
--- Comment #2 from Christoph Anton Mitterer <calestyo@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs