[erlang-bugs] standard ssh to erlang sshd gives default shell, not the one specified in ssh:daemon/3

[andrei zavada]

Hi Niclas & all,

I gave it a try, and have a few things to note.

1. The exec option is not documented; it would be nice if it was.

2. Execution of command passed on ssh commandline is indeed suppressed if
ssh:daemon is started with an {exec, {M,F,A}} option.  Plugging an empty
function as "F" could be a simple solution for the folks recently (rightly)
raising this as a security issue.

3. However, {exec, {M,F,A}} doesn't seem to work.  Following your example, I
couldn't get my fun called.  Looking into the sources in ssh_cli.erl, it
appears in this branch of handle_ssh_msg:

handle_ssh_msg({ssh_cm, ConnectionManager, 
		{exec, ChannelId, WantReply, Cmd}}, #state{exec=undefined} = State) -> {Reply, Status} =
		 exec(Cmd), write_chars(ConnectionManager, 
		ChannelId, io_lib:format("~p\n", [Reply])),
    ssh_connection:reply_request(ConnectionManager, WantReply, 
				 success, ChannelId),
    ssh_connection:exit_status(ConnectionManager, ChannelId, Status),
    ssh_connection:send_eof(ConnectionManager, ChannelId),
    {stop, ChannelId, State#state{channel = ChannelId, cm = ConnectionManager}};

handle_ssh_msg({ssh_cm, ConnectionManager,
		{exec, ChannelId, WantReply, Cmd}}, State) ->
    NewState = start_shell(ConnectionManager, Cmd, State),
    ssh_connection:reply_request(ConnectionManager, WantReply,
				 success, ChannelId),
    {ok, NewState#state{channel = ChannelId,
			cm = ConnectionManager}};

the second one, which is supposed to take effect when the user has supplied
an {exec, {M, F, A}} option, seems to never be reachable.

3. Down in start_shell and below, there is a call starting a group, similarly
to the way this is done for the regular, interactive shell.  IMHO, if all I
need is connect via ssh, exec my command and return, a simple function call
will suffice.

4. In the context of the project I am fitting ssh into, I need to know who is
the user wanting to exec a command via ssh <host> <command>; hence, the
solution you pointed out with {exec, {M,F,A}}, isn't suitable.  Even before, I
have prepared a patch (attached) for otp-13B04 to do exactly this.  This
patch will, likely with some fuzz, apply to otp-14A as well.

With my patch, you would call ssh:daemon/3 with something like this in the
Options parameter:

  Exec4User = fun(User, Cmd) -> do_something(User, Cmd), "Done" end,
  ssh:daemon(Port, Address, {{exec4user, Exec4User} | OtherOptions}),

5. The solution I am proposing is of a "works-for-me" kind; someone has to
look into why the {exec, {M,F,A}} fails.  In other words, there is little
sense for both exec and exec4user to coexist: let upstream decide.

Cheers,
Andrei Zavada


On Mon, 2 Aug 2010 14:22:09 +0200 (CEST)
Niclas Eklund <nick@REDACTED> wrote:

> 
> Hello!
> 
> Try something like:
> 
>    Exec = {Module, Function, ArgList},
>    ssh:daemon({0,0,0,0}, <PORT>, [{exec, Exec}|Options]).
> 
> Best regards,
> 
> Niclas @ Erlang/OTP
> 
> On Mon, 26 Jul 2010, andrei zavada wrote:
> 
> > Hi,
> >
> > Consider the case of starting ssh:daemon/3 with bespoke shell supplied as
> > {shell, {Module, Function, Args}} in the proplist as its third parameter.
> >
> > Everything works as expected if I just do (using openssh-5.5_p1, the
> > current version in Gentoo per this writing)
> >
> > $ ssh -p<port> localhost
> >
> > My shell is now invoked and is happily serving commands.  Once I try the
> > same with a command-line parameter, i.e.,
> >
> > $ ssh -p<port> localhost fafa
> >
> > (expecting "fafa" to be passed to my shell function), the server hands
> > "fafa" over to the Erlang standard shell, which prints:
> >
> > {error,{1,erl_parse,["syntax error before: ",[]]}}
> >
> > And, logically, appending a dot to "fafa" makes it a valid Erlang
> > expression, which gets me a nice
> >
> > fafa
> >
> > The expected behaviour is that sshd accept the command and feed it to the
> > custom shell the user specified in the Options proplist.
> >
> > This misbehaviour is verified in otp-12B-5, otp-13B04, as well as in
> > otp-14A. All systems were tested on a Gentoo box (~amd64 arch), built
> > from unpatched sources from erlang.org.
> >
> > Is this a bug, as I suppose it is?
> >
> > Regards
> > Andrei Zavada
> >
> > ________________________________________________________________
> > erlang-bugs (at) erlang.org mailing list.
> > See http://www.erlang.org/faq.html
> > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED
> >
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: exec4user.patch
Type: text/x-patch
Size: 5175 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20100803/e005216c/attachment.bin>