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?

This is perhaps a problem with the documentation.


This command:

$ ssh <remote-host-name> echo? '`hostname`'

gets the strings "echo" and "`hostname`" as arguments, but
on the server
side "echo" is run with the argument "remote-host-name".


The ssh manpage says:

 > If a command is specified, it is executed on the remote host instead 
of a login shell.


If "echo" is interpreted as a login shell, who interprets
"`hostname`"
as "remote-host-name" then, and why?

I found that in order to pass the string to the command run on the 
remote host verbatim it is necessary to escape every character in it, 
but it isn't clear why should this be necessary.


Perhaps this should be explained in the manpage.


Yuri

On Sat, 11 Jan 2020 at 12:46, Yuri <yuri at rawbw.com> wrote:
> If "echo" is interpreted as a login shell, who interprets
"`hostname`"
> as "remote-host-name" then, and why?
>
Echo is not used as a login shell.

In both cases it uses your shell, the difference being that in the "ssh
foo" case it runs a shell with arguments indicating it's an interactive
login (ie a "login shell" which is indicated by a leading
"-" in its argv,
and usually enables features like job control).  In the other case, it's
run via the shell using $SHELL -c "your command".
>
> I found that in order to pass the string to the command run on the
> remote host verbatim it is necessary to escape every character in it,
> but it isn't clear why should this be necessary.
>
The command you give is always handled on the server by your shell in some
fashion.  It has to be, because SSH only specifies an opaque string for the
remote command, so without doing so you would not be able to specify
arguments at all.

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

On 2020-01-11 01:38, Darren Tucker wrote:
> The command you give is always handled on the server by your shell in some
> fashion.  It has to be, because SSH only specifies an opaque string for the
> remote command, so without doing so you would not be able to specify
> arguments at all.

It's not obvious why does it have to be this way. ssh sends the command 
as an array of strings. The first string is the command, and the 
subsequent strings are arguments. It can easily call the same command 
with the same arguments on the remote host.


Also this sentence from the man page seems to be false:

 > If a command is specified, it is executed on the remote host instead 
of a login shell.

Login shell still interprets the command. Interestingly, the shell 
process isn't running on the remote host, the command is a direct child 
of sshd.


Yuri

Regardless of what the ssh specification says, the ability to run 
commands verbatim is very useful, and can be implemented with a new 
dedicated argument, for example -z. The specification can be like this:


 ???? -z
 ???????????? Disable argument expansion. When the command is run remotely,

 ???????????? ssh passes arguments to the remote command verbatim, as they

 ???????????? were supplied, without any expansions. If the command is a 
full

 ???????????? path, it would be run on the target with the arguments as 
they were

 ???????????? supplied. If the command is a relative path, it would be 
run in the

 ???????????? user's home directory. Otherwise the command would be resolved

 ???????????? through the PATH variable. In all cases, the arguments 
would be

 ???????????? passed to the command exactly as they were supplied to the ssh

 ???????????? command.


Yuri

On Sun, 12 Jan 2020, Yuri wrote:
> dedicated argument, for example -z. The specification can be like this:
The wording could need some translation by a native speaker, but the
idea of this feature request is certainly sound.

Of course you?d lose the ability to run multiple commands, redirect
I/O, etc. when using your proposed flag.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/
Tel: +49 228 54881-393 ? Fax: +49 228 54881-235
HRB 5168 (AG Bonn) ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg