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>