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

[raf]

On Sat, May 27, 2023 at 12:08:43AM +0200, Thorsten Glaser <t.glaser at tarent.de> wrote:

> On Fri, 26 May 2023, Mingye Wang (Artoria2e5) wrote:
> 
> > ssh(1) currently affords an argument-passing functionality, but as the manpage
> > states, all arguments are simply concatenated by space.
> 
> How else would it do that? The arguments are processed by the
> shell first then passed as an array of NUL-terminated strings.
> 
> > The modest proposal is that we put a giant CAVEATS section in the manual page.
> 
> That might be useful indeed.

I think that stating "all arguments are simply
concatenated by space" is arguably clear enough, but it
can be good to elaborate on even obvious implications.
It can save time, especially with an example.

So, perhaps this could be added to the existing
sentence/paragraph:

  "so any spaces in individual arguments must be
  quoted using the syntax of the destination
  user's login shell".

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"
  ssh user at host "ls -l 'a b'"

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
just for the documentation on that feature probably
won't see the CAVEAT section at all.

> > The less modest one is we throw out the "[argument ...]" part altogether. It
> 
> Absolutely not. This will break about all uses of ssh in existence.
> 
> > What about escaping the arguments? Nobody said the user has to use a POSIX
> 
> Absolutely not. This will break almost all uses of ssh in existence.

Not knowing the details of each user's login shell is
precisely the reason that ssh couldn't ever do the
quoting itself. Each shell is its own language with
conceivably different quoting notation. The user knows
what that language is because it's the shell they chose
to use. ssh doesn't. It only knows the path to the
login shell executable, and it hands the command over
to the login shell to parse and execute. ssh is smart
enough not to try to interpret the command itself in
any way. Any attempt to do so would limit ssh's ability
to execute arbitrary commands to only those that it can
interpret. So the user has to do the quoting themselves.

cheers,
raf

> bye,
> //mirabilos
> -- 
> 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!
>                         ****************************************************
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev