Dropbear cli-session

Sat Nov 8 22:47:12 AWST 2014

Hi Paul,

> 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

What's printing this bit? It seems like something is
treating a SSH_OPEN_IN_PROGRESS (99) return value as
failure rather than just returning that from newchansess?

Cheers,
Matt

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