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

[Jochen Bern]

On 27.05.23 00:08, Thorsten Glaser wrote:
> On Fri, 26 May 2023, Mingye Wang (Artoria2e5) wrote:
>> 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.

You are confusing "ssh(1) does (not) distinguish between 'command' and 
'argument(s)'" with "the 'command' may (not) be understood by the remote 
shell as having arguments". To ssh(1), as it currently stands, "command" 
is meant to be opaque, and omitting "[argument ...]" from the ssh(!) 
manpage would indicate just that. For all we know, the remote shell 
could break the command into parts at underscores, rather than whitespace.

Let's summarize the general situation, though:
-- We cannot reduce the local shell's influence re: quoting to zero as
    that's what the (interactive) user uses to input the (remote) command
    in the first place. (Ignoring the possibility of RemoteCommand in a
    (pseudo?) config file for the moment.)
-- We cannot reduce the remote shell's influence to zero as long as
    sshd(8) uses that to execute the command.
-- If we avoid that and execv() the command directly, we make the UI
    disparate from what the user experiences with an interactive login
    (shell aliases, env vars, ...).
Pick your poison ...

It could be argued that ssh(1) already offers a certain amount of 
*choices* influencing the remote shell (login shell or not, tty or not, 
both usually affecting the dotfiles the remote shell will load), so I 
*could* see a "switch to remote direct execv()" *option* on the (far) 
horizon, but not a change of the default behavior.

(Another *technical* possibility would be to use some sort of encoding 
on the command transmitted from ssh to sshd, and thus make that a fully 
transparent bit stream that can carry NULs into a hypothetical remote 
"shell" that can detect and interpret them, but that would still require 
a protocol extension and I'm not sure how the part of providing such as 
an input through the local shell could be made anything but a pain in 
the forefingers ...)

 From the point of terminology, taking the respective shells out of the 
equation makes the entire thing less of a "secure shell" or "remote 
login" and more like an RPC or distributed queueing system ...

Regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20230530/ce5188d9/attachment.p7s>