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. ItAbsolutely 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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
