Dropbear cli-session

Paul Lemay plemay at accedian.com
Wed Nov 5 22:09:52 AWST 2014


Hello Matt,

coming back to this project, I have tries the following as you suggested:

"If you want to run it all within Dropbear itself I'd modify
sessioncommand()  which handles subsystem requests. Rather
than calling ptycommand() or noptycommand() make it call
connect_remote() - have a look at newtcpdirect() for an
example. Set channel->writefd and channel->readfd to the
returned socket, and make sure you set ses.maxfd
appropriately. It's an asynchronous connection, but I think
it should work OK."

what happens, is that the client connects and the sequence of SSH
authorization  is executed properly. The Dropbear server establishes a TCP
connection with myserver. All this is good, then, as part of the
application protocol, myserver sends an HELLO message. The message is
received by Dropbear, encoded and sent to the client application. Dropbear
then receive a connection reset from the client.

TRACE  (28333) 1415195715.978336: > connection in progress: err = 99
TRACE  (28333) 1415195715.978341: leave netconfdirect: err 99 socketfd (7)
TRACE  (28333) 1415195715.978347: enter send_msg_channel_failure
TRACE  (28333) 1415195715.978362: leave send_msg_channel_failure
TRACE  (28333) 1415195715.978367: leave chansessionrequest
TRACE  (28333) 1415195715.978372: leave recv_msg_channel_request
TRACE  (28333) 1415195715.978391: empty queue dequeing
TRACE  (28333) 1415195715.978408: enter check_in_progress
TRACE  (28333) 1415195715.978428: enter send_msg_channel_open_confirmation
TRACE  (28333) 1415195715.978448: leave send_msg_channel_open_confirmation
TRACE  (28333) 1415195715.978458: leave check_in_progress: success
TRACE  (28333) 1415195715.978482: empty queue dequeing
TRACE  (28333) 1415195715.978580: send normal readfd
TRACE  (28333) 1415195715.978587: enter send_msg_channel_data
TRACE  (28333) 1415195715.978590: enter send_msg_channel_data isextended 0
fd 7
TRACE  (28333) 1415195715.978593: maxlen 16375
TRACE  (28333) 1415195715.978598: send_msg_channel_data: len 581 fd 7
TRACE  (28333) 1415195715.978624: leave send_msg_channel_data
TRACE  (28333) 1415195715.978644: empty queue dequeing
*[28333] Nov 05 08:55:15 Exit (plemay): Error reading: Connection reset by
peer       <---------------*
TRACE  (28333) 1415195715.978865: enter session_cleanup
TRACE  (28333) 1415195715.978873: enter chancleanup
TRACE  (28333) 1415195715.978877: channel 0 closing

The same suite of events work fine with sshd so I am sure there is probably
something missing in the initialization of the session. I have defines

const struct ChanType svrchansess = {
    0, /* sepfds */
    "session", /* name */
    newchansess, /* inithandler */
    NULL, /* checkclosehandler */
    chansessionrequest, /* reqhandler */
    closechansess, /* closehandler */
};

and made sure that it was calling a function very similar to
newtcpdirect(). Is there something that I do wrong or missing?




On 28 September 2014 09:33, Matt Johnston <matt at ucc.asn.au> wrote:

> If you want to run it all within Dropbear itself I'd modify
> sessioncommand()  which handles subsystem requests. Rather
> than calling ptycommand() or noptycommand() make it call
> connect_remote() - have a look at newtcpdirect() for an
> example. Set channel->writefd and channel->readfd to the
> returned socket, and make sure you set ses.maxfd
> appropriately. It's an asynchronous connection, but I think
> it should work OK.
>
> Another option would be to make a little helper script that runs
> 'nc host port' and add another special case like that for
> sftp in sessioncommand().
>
> Cheers,
> Matt
>
> On Thu, Sep 25, 2014 at 10:27:12AM -0400, Paul Lemay wrote:
> > Actually Matt,
> >
> > it is a NETCONF server that I am implementing but I was expecting to
> have a
> > TCP communication from dropbear! I see that you already trigger a
> subsystem
> > in such a context. Is it possible to setup a tcp communication link with
> > the server at this point in the code?
> >
> > On Thu, Sep 25, 2014 at 6:37 AM, Paul Lemay <plemay at accedian.com> wrote:
> >
> > > Hello Matt,
> > >
> > > Thanks for your reply.
> > >
> > > Let me provide additional information on what I am trying to do with
> > > Dropbear. There are several types of client applications (i.e., some
> > > running their own client version of SSH others running through the
> Dropbear
> > > SSH clients apps with prot forwarding). They are all looking for secure
> > > services provided by a single server (i.e., MyTcpServer). In other
> words,
> > > all SSH clients connects to a single Dropbear server for services
> provided
> > > by MyTcpServer. The other connections to the Dropbear server will be
> > > rejected by MyTcpServer because they won't support MyTcpServer XML
> > > protocol. Threfore, in my simple view of things, the Dropbear server
> > > instance provides the secure authentication and communication. All
> > > decrypted communication channels are forwarded to MyTcpServer.
> > >
> > > Hope this could help in finding a good solution.
> > >
> > > Best Regards!
> > >
> > > On Wed, Sep 24, 2014 at 1:01 PM, Paul Lemay <plemay at accedian.com>
> wrote:
> > >
> > >> Hello there,
> > >>
> > >> I have a SSH client browser. It is connected to the Dropbear server. I
> > >> would like to know if it is possible to tailor dropbear so that, once
> the
> > >> dropbear authentication process is completed, a connection is
> establish to
> > >> my local server ready to takeover TCP communication for this browser.
> > >>
> > >> I understand there is a cli-tcpfwd that seems to support this function
> > >> but I do not know how to use it. Are there some examples available?
> > >>
> > >
> > >
> >
> > --
> >
> >
> > Avis de confidentialité
> >
> > Les informations contenues dans le présent message et dans toute pièce
> qui
> > lui est jointe sont confidentielles et peuvent être protégées par le
> secret
> > professionnel. Ces informations sont à l’usage exclusif de son ou de ses
> > destinataires. Si vous recevez ce message par erreur, veuillez s’il vous
> > plait communiquer immédiatement avec l’expéditeur et en détruire tout
> > exemplaire. De plus, il vous est strictement interdit de le divulguer, de
> > le distribuer ou de le reproduire sans l’autorisation de l’expéditeur.
> > Merci.
> >
> > Confidentiality notice
> >
> > This e-mail message and any attachment hereto contain confidential
> > information which may be privileged and which is intended for the
> exclusive
> > use of its addressee(s). If you receive this message in error, please
> > inform sender immediately and destroy any copy thereof. Furthermore, any
> > disclosure, distribution or copying of this message and/or any attachment
> > hereto without the consent of the sender is strictly prohibited. Thank
> you.
>

-- 


Avis de confidentialité

Les informations contenues dans le présent message et dans toute pièce qui 
lui est jointe sont confidentielles et peuvent être protégées par le secret 
professionnel. Ces informations sont à l’usage exclusif de son ou de ses 
destinataires. Si vous recevez ce message par erreur, veuillez s’il vous 
plait communiquer immédiatement avec l’expéditeur et en détruire tout 
exemplaire. De plus, il vous est strictement interdit de le divulguer, de 
le distribuer ou de le reproduire sans l’autorisation de l’expéditeur. 
Merci.

Confidentiality notice

This e-mail message and any attachment hereto contain confidential 
information which may be privileged and which is intended for the exclusive 
use of its addressee(s). If you receive this message in error, please 
inform sender immediately and destroy any copy thereof. Furthermore, any 
disclosure, distribution or copying of this message and/or any attachment 
hereto without the consent of the sender is strictly prohibited. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20141105/a63ae63f/attachment-0001.htm 


More information about the Dropbear mailing list