https://bugzilla.mindrot.org/show_bug.cgi?id=3677
Darren Tucker <dtucker@dtucker.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dtucker@dtucker.net
--- Comment #1 from Darren Tucker <dtucker@dtucker.net> ---
(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
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
Darren Tucker <dtucker@dtucker.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dtucker@dtucker.net
--- Comment #1 from Darren Tucker <dtucker@dtucker.net> ---
(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
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs