command [argument ...] in ssh(1): a footgun

[raf]

On Sat, May 27, 2023 at 02:45:34AM +0200, Thorsten Glaser <t.glaser at tarent.de> wrote:

> On Sat, 27 May 2023, raf wrote:
> 
> >So, perhaps this could be added to the existing
> >sentence/paragraph:
> >
> >  "so any spaces in individual arguments must be
> 
> Must they? No, a single space will do just fine.

They do if you want the receiving shell to not interpret
the space as a separator between arguments.

> >  quoted using the syntax of the destination
> >  user's login shell".
> … keeping in mind the source shell’s quoting as well.
> 
> >If an example were needed, something like these should
> >make it clear:
> >
> >  ssh user at host ls -l "'a b'"
> >  ssh user at host "ls -l a\ b"
> 
> This one, incidentally, sends 'ls -l a b' to the remote shell.
>    ssh user at host "ls -l a\\ b"
> has the effect you want; the first backslash is eaten by the
> local shell.

Perhaps that depends on the local shell. It works with zsh.
Testing with dash would probably be better. That works too.
I think you might be wrong. I think the slash would only
be eaten by the local shell if it weren't inside doublequotes.

> >  ssh user at host "ls -l 'a b'"
> 
> But you could also just do:
>    ssh user at host ls -l \'a b\'
> 
> Only if it’s more than one space, or different whitespace,
> does this come into effect.

That wasn't one of my examples. That wouldn't work for
a file "a  b", as you say.

> The more important point is things like pipes and redirections anyway.

For them, the entire command needs to be quoted.

> >Putting the extra information in a separate CAVEAT
> >section is less helpful. I think it's better to put it
> >where the feature itself is documented. People looking
> 
> Perhaps, perhaps not. Too much information in one place might have
> the opposite effect. I’d rather give a short line there, with a
> reference to .Sx CAVEATS below.

Yes, as long as it explicitly refers the reader to CAVEAT.

> >Not knowing the details of each user's login shell is
> >precisely the reason that ssh couldn't ever do the
> 
> Yes, exactly.
> 
> But for…
> 	ssh remhost ls -l \>foo
> 
> … it MUST NOT quote the I/O redirection sign, otherwise
> the redirection would not work. That’s why I’m saying it
> needs not and must not quote.

The redirecton sign isn't a space. We're talking about spaces.
But the redirection does have to "quoted" locally otherwise
it would apply to the local process, but it would need to
be quoted like this:

  ssh remhost "ls -l >foo"

> bye,
> //mirabilos (current developer of a POSIX-compatible shell)
> -- 
> Infrastrukturexperte • tarent solutions GmbH
> Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
> Telephon +49 228 54881-393 • Fax: +49 228 54881-235
> HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
> Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
> 
>                         ****************************************************
> /⁀\ The UTF-8 Ribbon
> ╲ ╱ Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
>  ╳  HTML eMail! Also,     https://www.tarent.de/newsletter
> ╱ ╲ header encryption!
>                         ****************************************************