openssh bugs - Apr 2016 - [Bug 2563] New: ssh bash -c drops arguments of the first command send to the remote.

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

            Bug ID: 2563
           Summary: ssh bash -c drops arguments of the first command send
                    to the remote.
           Product: Portable OpenSSH
           Version: 6.9p1
          Hardware: ix86
                OS: Linux
            Status: NEW
          Severity: major
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: pjb at informatimago.com

$ ssh -n -x -T $remote /bin/bash -c 'echo a b c'
doesn't execute ssh 


$ /bin/bash -c 'echo a b c'
a b c
$ /bin/bash -c '/bin/bash -c "echo a b c"'
a b c
$  ssh -n -x -T localhost /bin/bash -c 'echo a b c'

$  ssh -n -x -T localhost /bin/bash -c ':;echo a b c'
a b c

$ rm bar
$ ssh localhost /bin/bash -c 'echo foo bar baz > ~/bar'
X11 forwarding request failed on channel 0
$ cat bar

$ rm bar
$ ssh -x -n -T localhost /bin/bash -c 'printf "%s\n" foo bar baz
>
~/bar'
printf: usage: printf [-v var] format [arguments]
$ ssh -x -n -T localhost /bin/bash -c 'echo foo foo foo;echo bar bar
bar'

bar bar bar
$ 

So, strangely enough, only the arguments of the first command are
removed; the command itself and the redirection are transmitted and
executed, as well as the following commands if any.


This occurs the same way on linux and on MacOSX (with bash 4.3 on
Linux, bash 3.2 on MacOSX) and the following versions of ssh; and this
occurs the same way whether we ssh to localhost, or remotely to a
different system.

$ ssh -V
OpenSSH_6.7p1 Debian-5+deb8u1, OpenSSL 1.0.1k 8 Jan 2015
$ 

$ ssh -V
OpenSSH_6.9p1, LibreSSL 2.1.8

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

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

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jjelen at redhat.com

--- Comment #1 from Jakub Jelen <jjelen at redhat.com> ---
It does not look like a bug. The `ssh` accepts single argument as an
command, even though everyone is misusing it to use more of them. From
manual page for ssh:

    ssh [...] [user@]hostname [command]

The correct wording of your command would be:

    ssh -n -x -T $remote "/bin/bash -c 'echo a b c'"

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

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

Pascal Bourguignon <pjb at informatimago.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|6.9p1                       |7.2p1
           Severity|major                       |enhancement
                 OS|Linux                       |All
           Priority|P5                          |P3
           Hardware|ix86                        |All

--- Comment #2 from Pascal Bourguignon <pjb at informatimago.com> ---
You're right, the documentation specifies a single argument for the
command, so we can't say it's a bug.


Then let's transform this into a feature request/enhancement, to
upgrade the syntax to:

   ssh ... [command [arguments...]]

to match the behavior of su and sudo, amongst other commands.


That said, it could be argued that eg. sudo also takes [command],
without documenting it accepting arguments, but it accepts them and it
processes them as expected:

$ sudo bash -c 'echo foo;echo bar'
foo
bar
$



If [command [arguments...]] wasn't documented and implemented, I would
move to signal an error when giving superfluous arguments (both to ssh
and sudo, and any other such command not documenting what it accepts).



There's an argument to be made for using only [command] for sudo, ssh
and the like (even su): shell expansions are dones in the caller shell,
so if we don't use a single command-and-argument parameter, we have
more risks of issuing "not-what-I-mean" commands such as:

    ssh $remote ls *

But again, if we take this argument and reject [command
[arguments...]], then it would be better for the user (and less risky)
to signal an error for such a command.

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

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

--- Comment #3 from Pascal Bourguignon <pjb at informatimago.com> ---
I've identified the reason of the observed behavior: bash -c takes a
single command (as documented), but if it is followed by arguments,
then they are used as "command line arguments", assigned to $0 $1 ...

For example:

$ bash -c 'echo $0 $@' foo \; echo bar
foo ; echo bar
$

so:
    ssh ... bash -c 'echo foo;echo bar'

sends and executes remotely:

    bash -c echo foo ; echo bar

with:

    bash -c echo foo

assigning foo to $0 (no other command line argument), bash executing
therefore just 'echo'.

Then something strange occurs, since it seems that the following
    ; echo bar
gets evaluated somehow (probably by a shell forked by ssh on the remote
side).



The whole situation is messy, and I definitely think that ssh should
either concatenate the arguments to make a single command to be
executed remotely, or it should signal an error when it's given
additionnal arguments, instead of forwarding them to the remote side to
be processed in ways that are not very strictly controlled, documented
or well known.

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
(In reply to Pascal Bourguignon from comment #3)
 > The whole situation is messy, and I definitely think that ssh
should
> either concatenate the arguments to make a single command to be
> executed remotely, or it should signal an error when it's given
> additionnal arguments, instead of forwarding them to the remote side
> to be processed in ways that are not very strictly controlled,
> documented or well known.
Unfortunately we're about 20 years too late to make changes to ssh's
argument handling. Doing so now would break a very large number of
working setups.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #5 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.