On Thu, Jun 2, 2016 at 2:06 PM, <pizdel...@gmail.com> wrote:
> On Thu, Jun 02, 2016 at 08:53:49AM +1000, Darren Tucker wrote:
> > > i'm inclined to disagree with this diff, for the following reasons:
> >
> > - other than the concatenation with spaces, it's not a behaviour of
> ssh(1)
> > but of the server at the other end of the connection, which might use sh
> -c
> > or might do something completely different depending on the server.
>
> The ssh(1) man page is already documenting quite exhaustively the behaviour
> of the server at the other end; it is assumed that you're connecting to
> a real ssh server. If that's not the case, there are a lot of things
> from that man page that do not work (just try ssh -R 0:host:port with a
> dropbear server).
>
That would be dropbear's fault; using zero for the bind port
in tcpip-forward requests is specified in RFC4254 section 7.1. The
behaviour of "exec" channel requests isn't specified other than the command
being a single string.
A better example of what you're referring to would be the inclusion of
~/.ssh/authorized_keys in the ssh(1) man page. That's definitely server
side (and dependent) behaviour. IMO that shouldn't be there either and I
don't think we should be adding more like it.
And please notice that's it's not sh -c as in system(3) or popen(3); if
> you have /foo/bar as your login shell in /etc/passwd, it's /foo/bar -c.
>
Well for sshd(8), if you have a shell specified, sure. If you don't it'll
use /bin/sh. If you have some other server it might do something
different. It depends on the server. I didn't cover every case in my one
sentence reply.
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
