openssh unix dev - Oct 2018 - The first command of a nested compound command receives no arguments

Hi,

Thanks to Timo and Christian for their answers.

On Sun, Oct 21, 2018 at 3:32 AM Timo Kilpilehto <timo at kilpilehto.fi>
wrote:
> eval sh -c "echo none of this makes any difference"
Where is it documented that ssh is going to eval my command?  The fact
remains that ssh does not transparently pass the command to the remote
host.

This pair of commands result in the same output (a blank line):

$ dash -c echo 1
$ ssh localhost dash -c echo 1

However, the following three pairs of commands result in different output:

$ dash -c 'echo 1'
$ ssh localhost dash -c 'echo 1'

$ dash -c echo\ 1
$ ssh localhost dash -c echo\ 1

$ dash -c 'echo\ 1'
$ ssh localhost dash -c 'echo\ 1'

It appears that what is happening is that ssh is flattening the
multiple command arguments to a single string without escaping them.
(I concede there may be no "standard" way to do such escaping.)

It also appears that the ssh protocol defines the command as a single
string, not an argv-style list of multiple strings.  (See section 6.5
of https://www.ssh.com/a/rfc4254.txt .)

It might be worth documenting the escape-less flattening of the
command (and the corresponding loss of information) on the ssh
manpage.  I could write something and submit a patch, if the openssh
developers are interested.

Cheers,

Parke

Hi,

On Sun, Oct 21, 2018 at 10:21:56AM -0700, Parke wrote:
> Thanks to Timo and Christian for their answers.
> 
> On Sun, Oct 21, 2018 at 3:32 AM Timo Kilpilehto <timo at
kilpilehto.fi> wrote:
> > eval sh -c "echo none of this makes any difference"
> 
> Where is it documented that ssh is going to eval my command?  The fact
> remains that ssh does not transparently pass the command to the remote
> host.
This is not a *ssh* thing, but a generic "how does quoting on unix work
if two levels of shell are involved".

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             gert at
greenie.muc.de

> On Sun, Oct 21, 2018 at 10:21:56AM -0700, Parke wrote:
> > Where is it documented that ssh is going to eval my command?  The fact
> > remains that ssh does not transparently pass the command to the remote
> > host.
On Sun, Oct 21, 2018 at 10:30 AM Gert Doering <gert at greenie.muc.de>
wrote:
> This is not a *ssh* thing, but a generic "how does quoting on unix
work
> if two levels of shell are involved".
It is not obvious (at least to me), nor is it documented (that I can
find), that ssh should be thought of as a shell.  Neither the
OpenSSH.com homepage nor the ssh manpage describe ssh as a shell.

If the ssh protocol could pass argv-style string lists (and this is
certainly technically possible), the protocol could be transparent and
command flattening could be avoided.

I claim the current behavior can be unexpected and is undocumented.

The current manpage describes:

ssh [snip] [user@]hostname [command]

I believe the manpage could improved to describe:

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

After all, ssh *does* accept commands with extra arguments.  (ssh
could exit with an error instead of accepting extra arguments.)
However, the current manpage fails to describe how those extra
arguments will be relayed to the remote host.

Cheers,

Parke

On Sun, Oct 21, 2018 at 07:30:44PM +0200, Gert Doering
wrote:
> On Sun, Oct 21, 2018 at 10:21:56AM -0700, Parke wrote:
> > On Sun, Oct 21, 2018 at 3:32 AM Timo Kilpilehto <timo at
kilpilehto.fi> wrote:
> > > eval sh -c "echo none of this makes any difference"
> > 
> > Where is it documented that ssh is going to eval my command?  The fact
> > remains that ssh does not transparently pass the command to the remote
> > host.
> 
> This is not a *ssh* thing, but a generic "how does quoting on unix
work
> if two levels of shell are involved".
This is an oversimplification.  It's an SSH thing to the extent that the
SSH protocol defines that command execution is done by passing a single
command string, the ssh client specifically joins its arguments using
spaces in order to send them to the server, and the ssh(1) manual page
doesn't explain what's going on at all.

There are of course limits to how much it can nail down, because the
exact behaviour depends on the remote user's shell; but the
documentation could at least explain that the client joins any
command-line arguments following the destination using spaces and sends
them to the server as a single string, which can then generally be
expected to pass them as an argument to "sh -c".  People who
aren't
especially familiar with the details of the SSH protocol but who are
using ssh as a building block would then have a better chance of working
out what quoting they need to use.

In general, it's a very good idea for commands that can invoke
subsidiary commands to document the quoting requirements even if they're
straightforward, as they're often non-trivial and the consequences of
getting quoting wrong can be unfortunate.

The protocol-level part of this is
https://bugzilla.mindrot.org/show_bug.cgi?id=2283.

-- 
Colin Watson                                       [cjwatson at debian.org]