https://bugzilla.mindrot.org/show_bug.cgi?id=3677
Darren Tucker <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from Darren Tucker <[email protected]> --- (In reply to Daniel from comment #0) > ssh me@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. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
