[Bug 2094] New: Executing commands via ssh on a remote host has different parameter passing properties
bugzilla-daemon at mindrot.org
bugzilla-daemon at mindrot.org
Sun Apr 21 00:02:58 EST 2013
https://bugzilla.mindrot.org/show_bug.cgi?id=2094
Bug ID: 2094
Summary: Executing commands via ssh on a remote host has
different parameter passing properties
Classification: Unclassified
Product: Portable OpenSSH
Version: 6.2p1
Hardware: Other
OS: OpenBSD
Status: NEW
Severity: normal
Priority: P5
Component: ssh
Assignee: unassigned-bugs at mindrot.org
Reporter: laurie at tratt.net
Consider the file /tmp/ap.sh which simply prints out all the arguments
to it:
#! /bin/sh
while [ $# -ge 1 ]; do
echo "arg: $1"
shift
done
If I create a C file ex_local.c:
#include <unistd.h>
int main(int argc, char** argv) {
execlp(argv[1], argv[1], "a", "a'b", NULL);
return 0;
}
and then compile and run it, the arguments passed to it are printed
out:
$ ex_local /tmp/ap.sh
a
a'b
$
which is correct. If I have this C file ex_ssh.c:
#include <unistd.h>
int main(int argc, char** argv) {
execlp("/usr/bin/ssh", "/usr/bin/ssh", argv[1], argv[2], "a",
"a'b", NULL);
return 0;
}
and run it:
$ ex_ssh somehost.com /tmp/ap.sh
zsh:1: unmatched '
then /tmp/ap.sh isn't even executed on the remote machine. This
surprised me, because (perhaps naively), I expected parameters passed
to a command to work identically whether that command is local or run
via ssh. Just to show that it isn't the fault of zsh on the remote
machine, other shells show the same problem even with a simpler version
of the escaping problem:
$ echo ls \'
'
$ ssh someotherhost.com echo ls \'
bash: -c: line 0: unexpected EOF while looking for matching `''
bash: -c: line 1: syntax error: unexpected end of file
The basic problem, as far as I can tell, is that ssh is passing
arguments as unprotected strings to the remote shell to execute the
command. In essence, "funny" characters (e.g. ') are being reevaluated
remotely, even though they would not locally.
Assuming I have got the right end of the stick so far (which is no by
no means guaranteed), it's not obvious to me what the best behaviour
should be. When a user executes a command via ssh, there is a soft
notion that a login shell will be executed, with the users normal
customisation, before the command is executed. I presume this is what
ssh is doing at the moment, and where the parameter problem occurs. The
only way I can see for arguments to be passed reliably is for ssh to
invoke a middle-man command which then execv's with precisely the
parameters passed to ssh itself. This might be rather heavy-weight for
most uses, and will break backwards compatibility (some people are
bound to have inadvertently come to rely on the current behaviour):
perhaps it could be enabled via an optional switch?
--
You are receiving this mail because:
You are watching the assignee of the bug.
More information about the openssh-bugs
mailing list