[Bug 3677] Proper excaping for ssh remote command line

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Tue Apr 9 10:02:29 AEST 2024


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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #1 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Daniel from comment #0)
> ssh me at myserver echo a 'b " c' d

If you don't need stdin, you can work around some of your examples by
specifying the shell you want and feeding the command via a here doc:

$ ssh localhost /bin/sh <<EOD
echo a "b ' c" d
EOD

a b ' c d

[...]
> I think it's easy to implement an escaping engine in the ssh client

It's not.  It's probably not even possible.  Even if it was, modifying
the sent command behind the user's back is dubious.

In the ssh spec, the "exec" channel request has a single command
string: https://datatracker.ietf.org/doc/html/rfc4254#section-6.5

and while you might be able to do it for *a* shell, you don't know what
the user's shell is at the other end.  Does your escaping work with
zsh?  csh?  tcsh?  fish?  You don't even know if the other end is
attached to a vaguely POSIX-like environment.  Does your escaping work
with Windows?  VMS?  z/OS?  NonStop?  Cisco routers?  A random
appliance?

To do what you're describing in a supportable way, it'd probably need
to be an "execv" protocol extension.  This has been discussed in the
past (eg https://marc.info/?l=openssh-unix-dev&m=110195952412587&w=2)
but it also has many potential problems: how do you handle fallback
when the extension is not supported?  Do you require a full path to the
executable?  if not, where do you get $PATH since the shell usually
sets it? and other environment variables?  These limitations (and
probably others) limit the potential utility of this approach too.

-- 
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.


More information about the openssh-bugs mailing list