openssh unix dev - Jan 2020 - Why are the arguments supplied for the command run through ssh interpreted by shell before they are passed to the command on the server side?

I do think it's a problem that, as far as I can see, the exact behaviour
of ssh command interpretation isn't explained anywhere in its man pages,
even though it seems like the only possibility if you understand the
protocol.  ssh(1) just says "If command is specified, it is executed on
the remote host instead of a login shell", but that doesn't provide any
hint about what quoting of metacharacters might be required, which is
important since ssh is often used as plumbing.

Now, I understand that ssh doesn't itself control how the command is
parsed: it just executes the user's shell with -c and the command as
arguments (passing the whole command as a single argument).  However,
that's not the only possible interpretation of the bit from ssh(1) that
I quote above, and it would be helpful to clarify the documentation to
say so explicitly.  People who need to work out subtle details of
quoting rules could then at least know to consult the documentation of
the appropriate shell.


Another thing that's poorly-explained in ssh(1) is the handling of the
case where the command is passed to ssh as multiple arguments (e.g. 'ssh
host echo foo' rather than 'ssh host "echo foo"').  The
behaviour is
that all the arguments are concatenated into a single string with a
space character between them, but as far as I can see ssh(1) makes no
mention of this whatsoever and so I don't think this is well-understood.
It's important to explain this because the following example is not
handled in the way that one might naturally expect:

  ssh host cat 'path with spaces'

The command sent to the server is the string "cat path with spaces",
which will then typically be split into four words by the shell at the
other end.  If you want to preserve the quoting then you need to write
it as something like this:

  ssh host "cat 'path with spaces'"

-- 
Colin Watson                                       [cjwatson at debian.org]

Hi,

On Sat, Jan 11, 2020 at 01:38:53PM +0000, Colin Watson
wrote:
>   ssh host cat 'path with spaces'
>   ssh host "cat 'path with spaces'"
Too many shells involved...

This is really not a "SSH problem" but a "unix command line *left
and right*
which both have ideas about interpretation of specific characters".

And yes, it can get highly annoying and frustrating.  Sometimes it can
be solved by passing the special-character-data through stdin...

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 2020-01-11 05:38, Colin Watson wrote:
> I do think it's a problem that, as far as I can see, the exact
behaviour
> of ssh command interpretation isn't explained anywhere in its man
pages,
> even though it seems like the only possibility if you understand the
> protocol.  ssh(1) just says "If command is specified, it is executed
on
> the remote host instead of a login shell", but that doesn't
provide any
> hint about what quoting of metacharacters might be required, which is
> important since ssh is often used as plumbing.

A practical problem stemming from this is "how to pass a string to the 
server verbatim". I just escaped every character with '\'. But is
this
excessive, or generally sufficient? I can't tell since it isn't clear 
how the arguments are processed, and by what shell. It's not documented.


Yuri

On Sat, Jan 11, 2020 at 02:52:13PM +0100, Gert Doering
wrote:
> On Sat, Jan 11, 2020 at 01:38:53PM +0000, Colin Watson wrote:
> >   ssh host cat 'path with spaces'
> >   ssh host "cat 'path with spaces'"
> 
> Too many shells involved...
> 
> This is really not a "SSH problem" but a "unix command line
*left and right*
> which both have ideas about interpretation of specific characters".
It's an SSH problem specifically in that I do not believe it is possible
to correctly determine what quoting to use from ssh(1) even if you
understand Unix shell quoting rules.

Changing ssh's behaviour now would be extremely disruptive, but that's
not what I was suggesting.

-- 
Colin Watson                                       [cjwatson at debian.org]