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

[Niclas Eklund]

Hello!

#1 It will be documented when it's supported.

#2 Will be considered.

#3 Use the following trace to confirm that your callback module is called:

  dbg:tracer().
  dbg:p(all, [call]).
  dbg:tpl(group,start, [{'_',[],[{return_trace}]}]).
  dbg:tpl(group,start_shell1, [{'_',[],[{return_trace}]}]).

If Exec == {shell, start, ["foo"]} and you run 'ssh -p 9999 localhost bar' 
you should see:

(<0.68.0>) call group:start_shell1(shell,start,["foo","bar"])

#4 The exec option will perhaps be extended with similar options that 
shell accepts.

Best regards,

Niclas @ Erlang/OTP

On Tue, 3 Aug 2010, andrei zavada wrote:

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