[Bug 3677] Proper excaping for ssh remote command line

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3677

--- Comment #3 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Daniel from comment #2)
> If the exec channel is a single string (I didn't know that), then
> ssh should only accept one argument.
> 
> Accepting multiple arguments and then doing some kind of wrong
> concatenation (wrong because it is incompatible with the usual
> shells) is a potential attack vector because the magic hides the
> actual limitation.

This behaviour dates back over 30 years to the original pre-OpenSSH
ssh-1.0.0 from 1995:
https://github.com/daztucker/historic-ssh/blob/5c43de2266c5fc887f5e389730019d4b1e5f586a/ssh.c#L475

Changing it now will break innumerable currently-working
setups/scripts/whatever.

> I have use cases like these:
> 
> ssh me at myserver tar c "/home/me/My Files" --exclude="*.bak" | tar xC
> /localdestination/
> 
> These are almost impossible to implement using the current
> implementation,

These are trivial to make work for a remote POSIX shell by
double-quoting the arguments containing spaces (or all arguments)
passed to ssh:

$ mkdir "/tmp/a dir"
$ touch "/tmp/a dir/foo.bak"

$ ssh localhost tar cf - --exclude="*.bak" '"/tmp/a dir"' | tar tfv -
tar: Removing leading `/' from member names
drwxrwxr-x dtucker/dtucker   0 2026-03-04 12:22 tmp/a dir/

> while the following commands work

These work because they are parsed by only a single shell.  If you
either structure them to be parsed by two shells, or avoid the second
shell using the /bin/sh stdin technique I described in my first comment
they'll work.

The current behaviour is not ideal, however every proposal to change it
so far, including this one, is worse.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.