Mailing List Archive

On Sat, 11 Jan 2020 at 12:46, Yuri <yuri@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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sat, 11 Jan 2020 at 20:59, Yuri <yuri@rawbw.com> wrote:
[...]
> 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.

Why do you say that? From RFC 4254 section 6.5:

"""
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "exec"
boolean want reply
string command

This message will request that the server start the execution of the
given command. The 'command' string may contain a path. Normal
precautions MUST be taken to prevent the execution of unauthorized
commands.
"""

Note the single string specifying the command.

> 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.

No, it's interpreted by a non-login shell. A login shell is a subset
of shell invocations with some specific behaviour. The bash man page
describes some of this:

"""
INVOCATION
A login shell is one whose first character of argument zero is a -, or
one started with the --login option.
[...]
Login shells:
On login (subject to the -noprofile option):
if /etc/profile exists, source it.

if ~/.bash_profile exists, source it,
else if ~/.bash_login exists, source it,
else if ~/.profile exists, source it.

On exit:
if ~/.bash_logout exists, source it.
"""

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

That's probably because the shell is skipping the fork in the simple
command case as an optimization. If you repeat the experiment with a
non-trivial command you'll see something like this:

$ ssh localhost "sleep 1000 | sleep 1000"
[...]
$ ps -eaf | grep "sleep 1000"
dtucker 22321 1 0 22:56 ? 00:00:00 bash -c sleep 1000 | sleep 1000
[...]
$ pstree -s -p 22355
systemd(1)---bash(22321)---sleep(22355)

--
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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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@debian.org]
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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@greenie.muc.de
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sat, 11 Jan 2020, Yuri wrote:

> 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

It doesn’t.

This works:

94 ssh root@$hostbase "
95 PS4='(${hostbase%%.*})++++ '
96 set -ex
97 psql -U veraweb -h 127.0.0.1 veraweb
98 rm -rf /var/lib/tomcat$tomcat/webapps/veraweb
99 rm -rf /var/lib/tomcat$tomcat/webapps/vwor
100 " <core/src/main/files/upgrade.sql

Here, $hostbase and $tomcat are expanded locally. Full code:
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=veraweb/veraweb.git;a=blob;f=upload.sh;h=b8b0cf92ad36dbc929afd86effe44d9bec888344;hb=HEAD

If you wish for no local expansion, quote locally, such as:

ssh -l luser remotehost '
command1
command2
…
'

Quote any ‘'’ inside as “'\''”, that’s it. (Easily done, for
example in AT&T ksh93/GNU bash/mksh: ${cmd//\'/\'\\\'\'})

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 2020-01-11 08:57, Thorsten Glaser wrote:
> If you wish for no local expansion, quote locally, such as:
>
> ssh -l luser remotehost '
> command1
> command2
> …
> '


This didn't work for me because single quotes only prevent local
expansion. The string is expanded on the remote host.


Yuri


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sat, 11 Jan 2020, Yuri wrote:

> On 2020-01-11 08:57, Thorsten Glaser wrote:
> > If you wish for no local expansion, quote locally, such as:
> >
> > ssh -l luser remotehost '
> > command1
> > command2
> > …
> > '

> This didn't work for me because single quotes only prevent local expansion.

Then you didn’t do it right.

> The string is expanded on the remote host.

Yes, “command1” is expanded remotely, but you use the quoting rules
of the remote shell INSIDE the single quotes for the local POSIX shell
to prevent that (just replace all ' with '\'' and you’re set).

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 2020-01-11 09:07, Thorsten Glaser wrote:
> Yes, “command1” is expanded remotely, but you use the quoting rules
> of the remote shell INSIDE the single quotes for the local POSIX shell
> to prevent that (just replace all ' with '\'' and you’re set).


It arrives to the remote host with the outer quotes stripped, and the
expansion takes place. Perhaps this would work '\'some command\''. Then
there should be double-quoting of any single-quote characters inside.


Yuri


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sat, 11 Jan 2020, Yuri wrote:

> On 2020-01-11 09:07, Thorsten Glaser wrote:
> > Yes, “command1” is expanded remotely, but you use the quoting rules
> > of the remote shell INSIDE the single quotes for the local POSIX shell
> > to prevent that (just replace all ' with '\'' and you’re set).
>
> It arrives to the remote host with the outer quotes stripped, and the
> expansion takes place.

No, it doesn’t.

$ ssh localhost 'echo "a string with '\'' and" '\''$pecial ch`aracters'\'' works'
a string with ' and $pecial ch`aracters works

The command that gets run remotely is:
echo "a string with ' and" '$pecial ch`aracters' works

This is handled according to normal quoting rules on the remote side,
as if you entered it interactively.

bye,
//mirabilos, shell developer (so knows what he’s saying)
--
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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sat, Jan 11, 2020 at 2:02 AM Yuri <yuri@rawbw.com> wrote:
>
> 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.

While it's important to understand how local shell processing works
(and this is obviously out-of-scope of the ssh(1) man page), I think
ssh(1) doesn't adequately explain how the "command" is executed on the
remote side, and how a command is formed from multiple command tokens.

From https://github.com/openssh/openssh-portable/blob/ed3ad71b17adcd1fb4431d145f53cee1c6a1135e/ssh.c#L1069-L1072,
you can see that multiple command tokens are simply joined with spaces
into a single actual "command". That implies that the remote side sees
all of the following variations as exactly equivalent:

$ ssh host 'printargs "foo bar" baz | cat' # ssh sees a single command
token locally
$ ssh host printargs '"foo' 'bar"' baz \| cat # ssh sees 6 command
tokens locally
$ ssh host printargs '"foo bar" baz |' cat # ssh sees 3 command tokens locally

From https://github.com/openssh/openssh-portable/blob/ed3ad71b17adcd1fb4431d145f53cee1c6a1135e/session.c#L1703-L1711,
you can see that these would all result approximately in running this
command remotely:

$SHELL -c 'printargs "foo bar" baz | cat'

I say "approximately" because for simpler presentation, I used shell
syntax above (as if you were to manually run the command in a remote
shell), but you can see from the source that ssh actually does this
via a fork-and-exec, so there would be no single quotes anywhere, for
example.

The output would look something like this:

argv[0] = {/usr/local/bin/printargs}
argv[1] = {foo bar}
argv[2] = {baz}

Here's a bash implementation of printargs:

#!/bin/bash

for (( i = 0; i <= $#; ++i )); do
printf 'argv[%d] = {%s}\n' $i "${!i}"
done
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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@debian.org]
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 2020-01-12 11:41, Thorsten Glaser wrote:
> The wording could need some translation by a native speaker, but the
> idea of this feature request is certainly sound.


This was English, not German, BTW.


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


You would lose the ability to redirect I/O in an immediate way, but you
would always be able to run a shell command like "/bin/sh" "-c"
"any-command | tee cmd.log | process-further" which would regain the
ability to do everything that a shell can do.


The problem from my original message, the ability to pass an arbitrary
shell script to a remote host, would become trivial.


Best,

Yuri


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, 12 Jan 2020, Yuri wrote:

> This was English, not German, BTW.

For some values of English, perhaps.

> You would lose the ability to redirect I/O in an immediate way, but you would
> always be able to run a shell command like "/bin/sh" "-c" "any-command | tee
> cmd.log | process-further" which would regain the ability to do everything
> that a shell can do.

Yes, but

ssh -z remhost sh -c "something"

is exactly identical to

ssh remhost "something"

:þ

//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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 2020-01-12 12:17, Thorsten Glaser wrote:
> Yes, but
>
> ssh -z remhost sh -c "something"
>
> is exactly identical to
>
> ssh remhost "something"


No it's not when "something" has odd characters in it.


Yuri


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, 12 Jan 2020, Yuri wrote:

> No it's not when "something" has odd characters in it.

It is.

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 01/11/2020 10:59 AM, Yuri wrote:
> 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's not obvious why does it have to be this way.

Because sshd ignoring the target account's configured, possibly
restricted, shell and running whatever executable the client asked for
would promise to be a backdoor large enough to drive an aircraft carrier
through. Sideways.

Not to mention that running commands on the server without having the
login shell set up the environment - $PATH, $LD_LIBRARY_PATH, etc. etc.
- would very likely be an issue no less complicated than figuring out
the nested quoting.

Regards,
--
Jochen Bern
Systemingenieur

Binect GmbH
Robert-Koch-Stra?e 9
64331 Weiterstadt

On 2020-01-13 00:14, Jochen Bern wrote:
> Because sshd ignoring the target account's configured, possibly
> restricted, shell and running whatever executable the client asked for
> would promise to be a backdoor large enough to drive an aircraft carrier
> through. Sideways.
>
> Not to mention that running commands on the server without having the
> login shell set up the environment - $PATH, $LD_LIBRARY_PATH, etc. etc.
> - would very likely be an issue no less complicated than figuring out
> the nested quoting.


Your objection is really only about how the command is handled, not its
arguments, and my concern is mostly how arguments are expanded.

So I would reformulate my suggestion:


???? -z
???????????? Disable command arguments expansion. When the command is

???????????? run remotely, ssh passes arguments to the remote command

???????????? verbatim, as they were supplied, without any expansions. The

???????????? command itself is treated the same way as commands are

???????????? treated without the -z argument.


Yuri


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Yuri wrote:
> my concern is mostly how arguments are expanded.

I think this is unlikely to change. Follow the previous advice;

echo 'only local unquote of $trange `chars' | ssh remote sh


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev