libssh based server
Hello, I'm trying to integrate a ssh server into an open source project I'm working at (eBrainPool - http://ebrain.in). I'd like to use libssh for this though I'm having some difficulty figuring out the server end of getting public key authentication and X tunneling and forwarding working. Most of the documentation and samples seem to be primarily for ssh clients though admittedly I could have missed out on the relevant documentation. The sample server code (samplesshd.c) does not demonstate public key authentication. I would appreciate if someone here could point me on the functions,etc required to get public key authentication working with libssh. Any pointers on tunneling and X forwarding would also be appreciated :) Thanks, jeetu ebrain.in | Beehive Computing Discover and run software from any device around you.
Re: libssh based server
Hey, > maybe Milo can give you some pointers, he has implemented it lately with > libssh 0.5 which will be released soon. I hope we have rc1 ready this week. > >-- andreas Thanks Andreas for the response.if Milo is on this list then I would sincerely appreciate any pointers :) As a backup till we can't implement a full libssh server in code, we plan to call sshd from within our code rerouting it's stdin,stdout and stderr and parsing results - this way at least our client has more control. If someone can point out the goods and bads of this strategy that would be very helpful too :) Thanks so much :) Bye for now Jeetu ebrain.in - Beehive Computing (an open source GPL project) Discover and run applications from any device around you
Re: libssh based server
Hi Milo, Totally appreciate your help towards libssh server side pubkey authentication :) I haven't worked extensively with libssh but I've been evaluating to use it to have a ssh server as part of an open source project I'm working on. The other option is to call sshd and reroute stdin and stdout. Any thoughts on either approach would be appreciated. Using libssh to build a server there are two areas that daunt me : - Pubkey Authentication - Creating a tunnel and X forwarding. Going through the libssh server side API (http://api.libssh.org/master/group__libssh__server.html) the ssh_handle_key_exchange function stands out as something that could possibly have bearing on this? This function is part of the newer libssh and not for the the libssh on my debian testing. If you could just point me in the right direction on both of the above would appreciate it :) Thanks so much. Bye for now Jeetu ebrain.in | Beehive Computing Discover and run software from any device around you
Re: libssh 0.5.0rc1
Hi Andreas, First, thanks to all you guys for working on a much needed (by me at least) ssh library :) I've been working on a libssh based server that handles public key authentication and X11 forwarding. Milo has been extremely instrumental in helping me out :) Just had a cursory look at the documentation and yes things are definitely a lot better, thank you again for this :) Jeetu ebrain.in Discover and run software from any device near you. On Wed, Mar 23, 2011 at 1:39 PM, Andreas Schneider wrote: > Hello, > > we are happy to announce libssh 0.5.0rc1. We consider this release as more > stable than 0.4.x so please go and test. We hope that this will be the last > release candidate :) > > * Added ssh_ prefix to all functions. > * Added complete Windows support. > * Added improved server support. > * Added unit tests for a lot of functions. > * Added asynchronous service request. > * Added a multiplatform ssh_getpass() function. > * Added a tutorial. > * Added a lot of documentation. > > http://www.libssh.org/2011/03/23/libssh-0-5-0rc1/ > > http://test.libssh.org/index.php?project=libssh > > > > -- andreas > > -- > Andreas Schneider GPG-ID: F33E3FC6 > www.cryptomilk.org a...@cryptomilk.org > > >
retrieving the exec command
Bonjour Milo,
Ca va?
Once the SSH_CHANNEL_REQUEST_EXEC message is retrieved by the server
how do I retrieve the command to be executed? Directly accessing the
ssh_message struct is probably not a good idea and also produces the
"Dereferencing pointer to incomplete type" error.
I think there should be a function within libssh similar for functions
to retrieve the X11 auth_cookie etc. I've made changes to the libssh
code I cloned from your tree and it seems to work fine, however I am
not sure if there is already a mechanism in libssh that I have not
discovered. I'm attaching the patch as to what I've done.
Would appreciate if you could let me know if this works or what I
should use instead.
Thanks,
Jeetu
diff --git a/include/libssh/server.h b/include/libssh/server.h
index cb12c13..29d57ed 100644
--- a/include/libssh/server.h
+++ b/include/libssh/server.h
@@ -349,6 +349,8 @@ LIBSSH_API int ssh_channel_write_stderr(ssh_channel channel,
const void *data,
uint32_t len);
+LIBSSH_API const char *ssh_message_channel_request_exec_command(ssh_message msg);
+
/* deprecated functions */
SSH_DEPRECATED LIBSSH_API int ssh_accept(ssh_session session);
SSH_DEPRECATED LIBSSH_API int channel_write_stderr(ssh_channel channel,
diff --git a/src/server.c b/src/server.c
index 48c7716..8f3a4b1 100644
--- a/src/server.c
+++ b/src/server.c
@@ -1025,6 +1025,10 @@ int ssh_message_global_request_port(ssh_message msg){
return msg->global_request.bind_port;
}
+const char *ssh_message_channel_request_exec_command(ssh_message msg){
+return msg->channel_request.command;
+}
+
/** @brief defines the ssh_message callback
* @param session the current ssh session
* @param[in] ssh_bind_message_callback a function pointer to a callback taking the
ssh_handle_packets blocking issue
Hi, As I've mentioned here before I've been trying to put together a SSH server with libssh that does pubkey authentication and X11 forwarding. Milo has been helping me with this a lot :) I've been using the libssh off Milo's tree wherein he's implemented server side X11 handling. I've been trying to debug a situation wherein the X11 forwarding works on occassion but otherwise mysteriously fails. Approximately the failure rate would be around 20% and the ssh client shows that the X11 channel is being created. I realized that when it fails the block occurs after ssh_channel_open_x11 within channel_open and in the call ssh_handle_packets(session,-1). Apparently the -1 causes this to block till there is an event. I tried replacing the -1 with a random number such as 2000 (milliseconds) and things work much better nowthere still is a failure rate with my X11 forwarding of about 2-5% (from 20%) but there seems to be an effect. Of course this was just a random trying to debug approach and I don't know enough of libssh to know whether the infinite timeout is required or what the real reason for this behaviour is, truthfully I'm not even sure if there's something I'm doing in my code that is manifesting in this error here - don't know what that could be though - only suspect I have is that in the call to ssh_channel_open_x11 for ip I am mentioning the ssh server ip and for port the port on which ssh port listens in for connections (not sure if this is what's supposed to go in here but seems that these are for logging anyway, but what is truly expected in these values and if they have an impact is a question I don't fully understand so thought I'd mention it here in case there's a link). I'd truly appreciate your help here since I don't understand the inner workings of libssh to be able to take it much further on my own - the random 2 second interval while it works in this case may not be apt in other situations for e.g. Also it still does fail on occassion even now. All the help is truly appreciated. If someone here is interested I could send across my server code so that maybe people can point out the bugs :) Bye for now ebrain.in Discover and run software from any device near you.
Re: ssh_handle_packets blocking issue
Hi Sharon, Thanks so much for your response :) > I found that ssh_handle_packets() was always blocking with a -1 after a > channel had been successfully created. > > > > I stepped through libssh a bit more and found that it was stuck in a > condition that it couldn’t ever get out of because the POLLERR flag was > being set on the events member of the pollfd struct and yet it was being > looked for on the revents member. Yes it seems similar to what I am seeing though I haven't tried to deduce what is causing the block. I could verify if my block is taking place for similar reasons such as what you mention if that helps someone here. A question that has been going through my mind has been if this is related to X11 specifically or other channels too and your reply answers that. I agree that a quick hack won't solve this, I have a temporary 2 second timeout but that's not the right way to do this. I'll try to collect more info on why things are failing at my end too, in the meantime if someone here needs me to try something specific in order to figure this please let me know. Thanks :) Bye for now Jeetu ebrain.in | Beehive Computing Discover and use software from any device around you.
Re: ssh_handle_packets blocking issue
Hi, > Hello Jeetu, Sharon, > I'll look at that issue asap. It's a blocking problem for release 0.5. >Aris Aris, Thanks so much :) Please let me know if you need me to try something or any further data to help you debug this. > If this is on Windows, which Windows version are you running? We have a > poll(2)-emulation for older Windows versions. This version doesn't set > POLLERR, maybe that's causing the problem. > Andreas, I'm seeing this behaviour on Linux (debian testing). Please let me know if you need any further info to debug this or if I can help in any way. Thanks so much yet again for a very nice piece of work :) Bye for now Jeetu ebrain.in | Beehive Computing Discover and run software from any device around you.
Re: ssh_handle_packets blocking issue
Hi, >> > Could you provide me a backtrace (with full symbols if possible) of >> > a >> > stuck process (with the -1 timeout) so I can have an idea of what >> > condition it's waiting for and why it doesn't arrive. >> > >> > A verbose log (with ssh_options_set) of the same session would >> > greatly >> > help, along with the code snippet you're using to handle ssh >> > connexions. Aris, will get on this right away :) Thanks guys for helping :) Bye for now ebrain.in | Beehive Computing Discover and run software from any device around you.
Re: ssh_handle_packets blocking issue
Hi Aris, >>> > A verbose log (with ssh_options_set) of the same session would >>> > greatly Am using the following code to produce debug output, I presume I should be seeing output on stderr however I'm unable to see any output from the library. I've checked the cmake libssh options and it has the WITH_DEBUG_CALLTRACE cmake option set. During installation of the library it says that it is installing the Debug installation profile. Would appreciate if someone could point me as to where I'm going wrong :) int verbosity = SSH_LOG_FUNCTIONS; sshbind=ssh_bind_new(); session=ssh_new(); ssh_options_getopt(session,&argc,argv); ssh_options_set(session, SSH_OPTIONS_LOG_VERBOSITY, &verbosity ); Thanks, Jeetu On Wed, Apr 6, 2011 at 9:16 AM, jeetu.gol...@gmail.com wrote: > Hi, > >>> > Could you provide me a backtrace (with full symbols if possible) of >>> > a >>> > stuck process (with the -1 timeout) so I can have an idea of what >>> > condition it's waiting for and why it doesn't arrive. >>> > >>> > A verbose log (with ssh_options_set) of the same session would >>> > greatly >>> > help, along with the code snippet you're using to handle ssh >>> > connexions. > > Aris, will get on this right away :) > > Thanks guys for helping :) > > Bye for now > > ebrain.in | Beehive Computing > Discover and run software from any device around you. >
Re: ssh_handle_packets blocking issue
Hi Aris,
I thought I'll also send across openssh client debug output taken both
when things work and when they fail, maybe this helps somehow too.
Thanks again.
Bye for now
On Wed, Apr 6, 2011 at 8:07 PM, jeetu.gol...@gmail.com
wrote:
> Hi Aris,
>
>> I think it's because the options from ssh_session are overriden by the
>> sshbind one. Either use ssh_bind_options_set (I think it's the name) or
>> call ssh_options_set after the ssh_bind_accept.
>
> Yup you were right, although ssh_bind_options_set didn't help but when
> I set log options with ssh_options_set after ssh_bind_accept it did
> the trick :)
>
> I'm attaching the logs I've collected along with a text with the code
> wherein things fall apart on some occassions.
>
> ...
> do {
> ssh_event_dopoll(event, 1000);
> } while(!ssh_channel_is_closed(chan_x11));
> ...
>
> this is basically the place where things fail, this is replica code
> from the samplesshd-tty.c file. Is the timeout value of 1000 too small
> here? should I have infinite blocking here too or increase this value?
>
> I'm also attaching the entire server code that i've been working on
> for eBrainPool (http://ebrain.in)...beware tough it's laden with
> printfs i've put in for debugging...and heavily laden with bugs I
> suppose ;)...work in progress.
>
> Thanks so much guys for all the help truly appreciate it :)
>
> Bye for now
>
jeetu@debian:~/code/misc$ ssh jeetu@localhost -p 2000 -vvv -X xeyes
OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /home/jeetu/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 2000.
debug1: connect to address ::1 port 2000: Connection refused
debug1: Connecting to localhost [127.0.0.1] port 2000.
debug1: Connection established.
debug3: Not a RSA1 key file /home/jeetu/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-END'
debug3: key_read: missing keytype
debug1: identity file /home/jeetu/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-1024
debug1: identity file /home/jeetu/.ssh/id_rsa-cert type -1
debug1: identity file /home/jeetu/.ssh/id_dsa type -1
debug1: identity file /home/jeetu/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version libssh-0.5.0
debug1: no match: libssh-0.5.0
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit:
ssh-rsa-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,z...@openssh.com,zlib
debug2: kex_parse_kexinit: none,z...@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-dss,ssh-rsa
debug2: kex_parse_kexinit:
aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc
debug2: kex_parse_kexinit:
aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc
debug2: kex_parse_kexinit: hmac-sha1
debug2: kex_parse_kexin
Re: ssh_handle_packets blocking issue
Hi,
> I just ran into this issues as well using Windows. Here's the
> backtrace:
Oliver, this is interesting. I'm very intrigued to know if this manifests in
the
same way like how I am seeing? Is your code part of a server or client?
In my case this behaviour and blocking occurs on some occasions is that
how you are seeing it too?
Aris, any luck or anything you would like me to try?
Bye for now.
On Tue, Apr 12, 2011 at 1:58 PM, Oliver Stöneberg wrote:
> I just ran into this issues as well using Windows. Here's the
> backtrace:
>
>ntdll.dll!775ff8c1()
>[Frames below may be incorrect and/or missing, no symbols loaded
> for ntdll.dll]
>ntdll.dll!775ff8c1()
>mswsock.dll!723d6f0f()
>mswsock.dll!723d6d30()
>ws2_32.dll!75eb2f7d()
>ws2_32.dll!75eb6a28()
>shell32.dll!762f11f0()
>libssh.dll!bsd_poll(ssh_pollfd_struct * fds=0x06b87ba8, unsigned
> long nfds=1, int timeout=-1) Line 212 + 0x2e bytes C
> > libssh.dll!ssh_poll(ssh_pollfd_struct * fds=0x06b87ba8, unsigned
> long nfds=1, int timeout=-1) Line 289 + 0x14 bytes C
>libssh.dll!ssh_poll_ctx_dopoll(ssh_poll_ctx_struct *
> ctx=0x06b8b778, int timeout=-1) Line 635 + 0x17 bytes C
>libssh.dll!ssh_handle_packets(ssh_session_struct *
> session=0x06b8bbc8, int timeout=-1) Line 390 + 0xd bytes C
>libssh.dll!ssh_channel_get_exit_status(ssh_channel_struct *
> channel=0x06b8ecb8) Line 2376 + 0xe bytes C
>[External Code]
>
> Pretty strange, that it is using bsd_pool. Looks like an issue in
> ssh_poll_init(). It doesn't set ssh_poll_emu to wsa_poll when it is
> available.
>
>
> > Hi Aris,
> >
> > I thought I'll also send across openssh client debug output taken both
> > when things work and when they fail, maybe this helps somehow too.
> >
> > Thanks again.
> >
> > Bye for now
> >
> > On Wed, Apr 6, 2011 at 8:07 PM, jeetu.gol...@gmail.com
> > wrote:
> > > Hi Aris,
> > >
> > >> I think it's because the options from ssh_session are overriden by the
> > >> sshbind one. Either use ssh_bind_options_set (I think it's the name)
> or
> > >> call ssh_options_set after the ssh_bind_accept.
> > >
> > > Yup you were right, although ssh_bind_options_set didn't help but when
> > > I set log options with ssh_options_set after ssh_bind_accept it did
> > > the trick :)
> > >
> > > I'm attaching the logs I've collected along with a text with the code
> > > wherein things fall apart on some occassions.
> > >
> > > ...
> > > do {
> > >ssh_event_dopoll(event, 1000);
> > >} while(!ssh_channel_is_closed(chan_x11));
> > > ...
> > >
> > > this is basically the place where things fail, this is replica code
> > > from the samplesshd-tty.c file. Is the timeout value of 1000 too small
> > > here? should I have infinite blocking here too or increase this value?
> > >
> > > I'm also attaching the entire server code that i've been working on
> > > for eBrainPool (http://ebrain.in)...beware tough it's laden with
> > > printfs i've put in for debugging...and heavily laden with bugs I
> > > suppose ;)...work in progress.
> > >
> > > Thanks so much guys for all the help truly appreciate it :)
> > >
> > > Bye for now
> > >
> >
>
>
>
>
Re: ssh_handle_packets blocking issue
ah sadly this seems different from what I am observing :(...though I am
curious if something in my code could somehow be causing this effectif
someone here could go through my code (sent earlier) or throw any light I'd
appreciate it profusely :)
On Tue, Apr 12, 2011 at 3:17 PM, Oliver Stöneberg wrote:
> Hey,
>
> seems like this was actually my fault. The hang happened in
> ssh_channel_get_exit_status(). After chatting with Aris it turned
> out, that it wasn't enough to just call ssh_channel_send_eof() before
> that, but I also needed to call ssh_channel_close() to assure the
> channel is actually closed.
>
> Also the issue with the poll function I mentioned is already fixed in
> the latest code. I am using an older version at the moment.
>
> Greetings
> Oliver
>
> > Hi,
> >
> > > I just ran into this issues as well using Windows. Here's the
> > > backtrace:
> >
> > Oliver, this is interesting. I'm very intrigued to know if this manifests
> in
> > the
> > same way like how I am seeing? Is your code part of a server or client?
> > In my case this behaviour and blocking occurs on some occasions is that
> > how you are seeing it too?
> >
> > Aris, any luck or anything you would like me to try?
> >
> > Bye for now.
> >
> >
> >
> > On Tue, Apr 12, 2011 at 1:58 PM, Oliver Stöneberg >wrote:
> >
> > > I just ran into this issues as well using Windows. Here's the
> > > backtrace:
> > >
> > >ntdll.dll!775ff8c1()
> > >[Frames below may be incorrect and/or missing, no symbols loaded
> > > for ntdll.dll]
> > >ntdll.dll!775ff8c1()
> > >mswsock.dll!723d6f0f()
> > >mswsock.dll!723d6d30()
> > >ws2_32.dll!75eb2f7d()
> > >ws2_32.dll!75eb6a28()
> > >shell32.dll!762f11f0()
> > >libssh.dll!bsd_poll(ssh_pollfd_struct * fds=0x06b87ba8, unsigned
> > > long nfds=1, int timeout=-1) Line 212 + 0x2e bytes C
> > > > libssh.dll!ssh_poll(ssh_pollfd_struct * fds=0x06b87ba8,
> unsigned
> > > long nfds=1, int timeout=-1) Line 289 + 0x14 bytes C
> > >libssh.dll!ssh_poll_ctx_dopoll(ssh_poll_ctx_struct *
> > > ctx=0x06b8b778, int timeout=-1) Line 635 + 0x17 bytes C
> > >libssh.dll!ssh_handle_packets(ssh_session_struct *
> > > session=0x06b8bbc8, int timeout=-1) Line 390 + 0xd bytes C
> > >libssh.dll!ssh_channel_get_exit_status(ssh_channel_struct *
> > > channel=0x06b8ecb8) Line 2376 + 0xe bytes C
> > >[External Code]
> > >
> > > Pretty strange, that it is using bsd_pool. Looks like an issue in
> > > ssh_poll_init(). It doesn't set ssh_poll_emu to wsa_poll when it is
> > > available.
> > >
> > >
> > > > Hi Aris,
> > > >
> > > > I thought I'll also send across openssh client debug output taken
> both
> > > > when things work and when they fail, maybe this helps somehow too.
> > > >
> > > > Thanks again.
> > > >
> > > > Bye for now
> > > >
> > > > On Wed, Apr 6, 2011 at 8:07 PM, jeetu.gol...@gmail.com
> > > > wrote:
> > > > > Hi Aris,
> > > > >
> > > > >> I think it's because the options from ssh_session are overriden by
> the
> > > > >> sshbind one. Either use ssh_bind_options_set (I think it's the
> name)
> > > or
> > > > >> call ssh_options_set after the ssh_bind_accept.
> > > > >
> > > > > Yup you were right, although ssh_bind_options_set didn't help but
> when
> > > > > I set log options with ssh_options_set after ssh_bind_accept it did
> > > > > the trick :)
> > > > >
> > > > > I'm attaching the logs I've collected along with a text with the
> code
> > > > > wherein things fall apart on some occassions.
> > > > >
> > > > > ...
> > > > > do {
> > > > >ssh_event_dopoll(event, 1000);
> > > > >} while(!ssh_channel_is_closed(chan_x11));
> > > > > ...
> > > > >
> > > > > this is basically the place where things fail, this is replica code
> > > > > from the samplesshd-tty.c file. Is the timeout value of 1000 too
> small
> > > > > here? should I have infinite blocking here too or increase this
> value?
> > > > >
> > > > > I'm also attaching the entire server code that i've been working on
> > > > > for eBrainPool (http://ebrain.in)...beware tough it's laden with
> > > > > printfs i've put in for debugging...and heavily laden with bugs I
> > > > > suppose ;)...work in progress.
> > > > >
> > > > > Thanks so much guys for all the help truly appreciate it :)
> > > > >
> > > > > Bye for now
> > > > >
> > > >
> > >
> > >
> > >
> > >
> >
>
>
>
>
Re: ssh_handle_packets blocking issue
Hi guys, Just wanted to know if someone has had luck reproducing (and hopefully resolving :) ) the ssh_handle_packets blocking behaviour I mentioned earlier? Or can someone verify if my code is not at fault? I've tested the master tree of libssh and I still see this behaviour. Earlier on a lot of the X server code was in Milo's personal tree that I was using that has been merged into the the master. Please let me know if there's more info I can providewould love to see this resolved :) Thanks again. Bye for now On Tue, Apr 12, 2011 at 4:44 PM, jeetu.gol...@gmail.com < jeetu.gol...@gmail.com> wrote: > > ah sadly this seems different from what I am observing :(...though I am > curious if something in my code could somehow be causing this effectif > someone here could go through my code (sent earlier) or throw any light I'd > appreciate it profusely :) > > > > > On Tue, Apr 12, 2011 at 3:17 PM, Oliver Stöneberg wrote: > >> Hey, >> >> seems like this was actually my fault. The hang happened in >> ssh_channel_get_exit_status(). After chatting with Aris it turned >> out, that it wasn't enough to just call ssh_channel_send_eof() before >> that, but I also needed to call ssh_channel_close() to assure the >> channel is actually closed. >> >> Also the issue with the poll function I mentioned is already fixed in >> the latest code. I am using an older version at the moment. >> >> Greetings >> Oliver >> >> > Hi, >> > >> > > I just ran into this issues as well using Windows. Here's the >> > > backtrace: >> > >> > Oliver, this is interesting. I'm very intrigued to know if this >> manifests in >> > the >> > same way like how I am seeing? Is your code part of a server or client? >> > In my case this behaviour and blocking occurs on some occasions is that >> > how you are seeing it too? >> > >> > Aris, any luck or anything you would like me to try? >> > >> > Bye for now. >> > >> > >> > >> > On Tue, Apr 12, 2011 at 1:58 PM, Oliver Stöneberg > >wrote: >> > >> > > I just ran into this issues as well using Windows. Here's the >> > > backtrace: >> > > >> > >ntdll.dll!775ff8c1() >> > >[Frames below may be incorrect and/or missing, no symbols >> loaded >> > > for ntdll.dll] >> > >ntdll.dll!775ff8c1() >> > >mswsock.dll!723d6f0f() >> > >mswsock.dll!723d6d30() >> > >ws2_32.dll!75eb2f7d() >> > >ws2_32.dll!75eb6a28() >> > >shell32.dll!762f11f0() >> > >libssh.dll!bsd_poll(ssh_pollfd_struct * fds=0x06b87ba8, >> unsigned >> > > long nfds=1, int timeout=-1) Line 212 + 0x2e bytes C >> > > > libssh.dll!ssh_poll(ssh_pollfd_struct * fds=0x06b87ba8, >> unsigned >> > > long nfds=1, int timeout=-1) Line 289 + 0x14 bytes C >> > >libssh.dll!ssh_poll_ctx_dopoll(ssh_poll_ctx_struct * >> > > ctx=0x06b8b778, int timeout=-1) Line 635 + 0x17 bytes C >> > >libssh.dll!ssh_handle_packets(ssh_session_struct * >> > > session=0x06b8bbc8, int timeout=-1) Line 390 + 0xd bytes C >> > >libssh.dll!ssh_channel_get_exit_status(ssh_channel_struct * >> > > channel=0x06b8ecb8) Line 2376 + 0xe bytes C >> > >[External Code] >> > > >> > > Pretty strange, that it is using bsd_pool. Looks like an issue in >> > > ssh_poll_init(). It doesn't set ssh_poll_emu to wsa_poll when it is >> > > available. >> > > >> > > >> > > > Hi Aris, >> > > > >> > > > I thought I'll also send across openssh client debug output taken >> both >> > > > when things work and when they fail, maybe this helps somehow too. >> > > > >> > > > Thanks again. >> > > > >> > > > Bye for now >> > > > >> > > > On Wed, Apr 6, 2011 at 8:07 PM, jeetu.gol...@gmail.com >> > > > wrote: >> > > > > Hi Aris, >> > > > > >> > > > >> I think it's because the options from ssh_session are overriden >> by the >> > > > >> sshbind one. Either use ssh_bind_options_set (I think it's the >> name) >> > > or >> > > > >> call ssh_options_set after the ssh_bind_accept. >
Re: Is libssh thread safe
Hi, >So, that means, everytime I want to execute a remote command, if I create a separate thread, and create a new session and a >channel > dedicated for this thread, then executing remote command with this session/channel will be safe, and each thread will work >fine without > impacting others, right? Zhang, Aris I have a similar use case such as above, have just implemented the above scenario in my own code but there are other changes in the code before I can comment on how well this works or doesn't. In the meantime would be great to hear on what is the recommended approach in the following scenarios : - a server that needs to to accept connections from multiple hosts - each connection would then have multiple requests it would have to service (mostly sequential but may also be in parallel) Thanks guys. Bye for now Jeetu ebrain.in | Beehive Computing Discover and run software from any device around you - an open source (GPL) project. On Fri, May 20, 2011 at 9:12 PM, Zhang Qian wrote: > Thanks Aris. > > So, that means, everytime I want to execute a remote command, if I create a > separate thread, and create a new session and a channel dedicated for this > thread, then executing remote command with this session/channel will be > safe, and each thread will work fine without impacting others, right? > > Why I asked that use case is for performance concern, my program will rely > on libssh to do a lot of remote command execution on the same remote host, > and each command will be done in a separate thread. So in each thread, > creating a dedicated session/channel and do the login with username/password > looks not good from performance point view, so I am wondering if I can keep > a global session/channel, and just do login one time before I create any > threads to execute any command remotely. > > Any suggestions on my use case? Thanks! >
Re: instability
Hi Aris,
>With libssh 0.5, it's a little different, you have to initialize libssh
threads and call ssh_init(). (libssh does the dirty work of initilalizing
>libcrypto or libgcrypt).
Just want to clarify if what I'm doing for my libssh server is all right. In
principle I have a new ssh_session created for each new connection into the
server.
My ssh_bind is common for all threads and I call ssh_bind_listen. I have a
ssh_session *session (therefore session is a pointer to a pointer) and I
init this pointer first with an session = ssh_new().I then move into a
loop where I init an individual session element such as
session[session_count] = ssh_new and then move onto waiting to accept a
connection with a ssh_bind_option...authenticating user...and finally if
authenticated create a new glib thread for that server sessionincremenet
session_count and this loops.
Sorry for trying to describe code instead of pasting the relevant snippet
here but I don't have access to my comp with the code right now.
Does the above seem in principle to be acceptable and in line with libssh's
threading modelor would ppl recommend a better way to have a
multi-threaded server.
Thanks,
Bye
On Tue, May 24, 2011 at 2:54 AM, Paulo Panhoto wrote:
> There are several threads running but each session is only accessed by one
> thread.
>
> Sure, it does help. thanks.
>
>
> On Mon, May 23, 2011 at 6:22 PM, Aris Adamantiadis wrote:
>
>> Hi Paulo,
>>
>> Are you using libssh in several threads ? Libssh is threadsafe under two
>> conditions : call ssh_init() outside of threads and initialize threading in
>> the crypto library (http://www.openssl.org/support/faq.html#PROG1).
>> With libssh 0.5, it's a little different, you have to initialize libssh
>> threads and call ssh_init(). (libssh does the dirty work of initilalizing
>> libcrypto or libgcrypt).
>>
>> Hope this helps,
>>
>> Aris
>>
>> Le 23/05/11 21:41, Paulo Panhoto a écrit :
>>
>> Hello,
>>>
>>> I'm writing a Qt app with libssh. The best approach I've got was this:
>>> wrap ssh in a QThread that emits signals to other components.
>>>
>>>
>>> session = ssh_new();
>>>
>>> if (session == NULL)
>>> {
>>> throw SSHException(tr("ssh_new failed"));
>>> }
>>> const std::string & stdHost = host.toStdString();
>>> ssh_options_set(session, SSH_OPTIONS_HOST, stdHost.c_str());
>>> ssh_options_set(session, SSH_OPTIONS_PORT, &port);
>>> ssh_options_set(session, SSH_OPTIONS_SSH1, &disabled);
>>> ssh_options_set(session, SSH_OPTIONS_SSH2, &enabled);
>>>
>>> emit stateChanged(CONNECTING);
>>> emit debugInfo(tr("Conecting to %0:%1").arg(host).arg(port));
>>> if (ssh_connect(session) != SSH_OK)
>>> {
>>> throw SSHException(QString("ssh_connect:
>>> %1").arg(ssh_get_error(session)));
>>> }
>>>
>>> This piece of code is causing me trouble: I'm running it on a opensuse
>>> 11.3 and tested it with libssh 0.4.2 (the "branding" release) and 0.4.8.
>>>
>>> When I compile it against OpenSSL, I get aborts due to double free
>>> inside libcrypto: works most of the time when I run it natively.
>>> Nevertheless, when the program is run via xming server, the error rate
>>> is almost 100%
>>> libopenssl 1.0.0-6.7.1 - x86_64
>>>
>>> #0 0x75aca9e5 in raise () from /lib64/libc.so.6
>>> #1 0x75acbee6 in abort () from /lib64/libc.so.6
>>> #2 0x75b05c53 in __libc_message () from /lib64/libc.so.6
>>> #3 0x75b0b226 in malloc_printerr () from /lib64/libc.so.6
>>> #4 0x75b0e8e3 in _int_realloc () from /lib64/libc.so.6
>>> #5 0x75b10142 in realloc () from /lib64/libc.so.6
>>> #6 0x74ca6d4f in CRYPTO_realloc () from
>>> /lib64/libcrypto.so.1.0.0
>>> #7 0x74d0d2a8 in lh_insert () from /lib64/libcrypto.so.1.0.0
>>> #8 0x74ca980c in OBJ_NAME_add () from /lib64/libcrypto.so.1.0.0
>>> #9 0x74d1a66b in OpenSSL_add_all_digests () from
>>> /lib64/libcrypto.so.1.0.0
>>> #10 0x77bac3cc in ssh_crypto_init () at
>>> /home/paulo/Downloads/oss-src/libssh-0.4.8/libssh/dh.c:144
>>> #11 0x77bae8f1 in ssh_init () at
>>> /home/paulo/Downloads/oss-src/libssh-0.4.8/libssh/init.c:47
>>> #12 0x77ba929c in ssh_connect (session=0xc3b8e0)
>>>
>>> If I compile it against libgcrypt, it fails all the time due to an
>>> assertion failure -- ath.c:193: _gcry_ath_mutex_lock: Assertion `*lock
>>> == ((ath_mutex_t) 0)' failed.
>>> libgcrypt 1.4.4-6.1 - x86-64
>>>
>>> #0 0x75ac79e5 in raise () from /lib64/libc.so.6
>>> #1 0x75ac8ee6 in abort () from /lib64/libc.so.6
>>> #2 0x74fdcaa8 in ?? () from /lib64/libgcrypt.so.11
>>> #3 0x74fdd1c7 in ?? () from /lib64/libgcrypt.so.11
>>> #4 0x74fd75f6 in ?? () from /lib64/libgcrypt.so.11
>>> #5 0x74fd7792 in ?? () from /lib64/libgcrypt.so.11
>>> #6 0x77ba8f7b in ssh_crypto_init ()
>>> at /hom
Re: instability
Hi Aris,
> If you are using server support, I strongly recommend that you use
> libssh 0.5rc1, in which we fixed many bugs for servers. In that case,
> please read http://api.libssh.org/master/libssh_tutor_threads.html for
> more info on threading.
>
>
I'm using the current libssh in master, will go through the documentation :)
thanks a lot :)
Bye for now
> Kr,
>
> Aris
>
> Le 24/05/11 05:47, jeetu.gol...@gmail.com a écrit :
> > Hi Aris,
> >
> >>With libssh 0.5, it's a little different, you have to initialize libssh
> > threads and call ssh_init(). (libssh does the dirty work of
> > initilalizing >libcrypto or libgcrypt).
> >
> > Just want to clarify if what I'm doing for my libssh server is all
> > right. In principle I have a new ssh_session created for each new
> > connection into the server.
> >
> > My ssh_bind is common for all threads and I call ssh_bind_listen. I have
> > a ssh_session *session (therefore session is a pointer to a pointer) and
> > I init this pointer first with an session = ssh_new().I then move
> > into a loop where I init an individual session element such as
> > session[session_count] = ssh_new and then move onto waiting to accept a
> > connection with a ssh_bind_option...authenticating user...and finally if
> > authenticated create a new glib thread for that server
> > sessionincremenet session_count and this loops.
> >
> > Sorry for trying to describe code instead of pasting the relevant
> > snippet here but I don't have access to my comp with the code right now.
> >
> > Does the above seem in principle to be acceptable and in line with
> > libssh's threading modelor would ppl recommend a better way to have
> > a multi-threaded server.
> >
> > Thanks,
> >
> > Bye
> >
> >
> > On Tue, May 24, 2011 at 2:54 AM, Paulo Panhoto > <mailto:paulo.panh...@gmail.com>> wrote:
> >
> > There are several threads running but each session is only accessed
> > by one thread.
> >
> > Sure, it does help. thanks.
> >
> >
> > On Mon, May 23, 2011 at 6:22 PM, Aris Adamantiadis
> > mailto:a...@0xbadc0de.be>> wrote:
> >
> > Hi Paulo,
> >
> > Are you using libssh in several threads ? Libssh is threadsafe
> > under two conditions : call ssh_init() outside of threads and
> > initialize threading in the crypto library
> > (http://www.openssl.org/support/faq.html#PROG1).
> > With libssh 0.5, it's a little different, you have to initialize
> > libssh threads and call ssh_init(). (libssh does the dirty work
> > of initilalizing libcrypto or libgcrypt).
> >
> > Hope this helps,
> >
> > Aris
> >
> > Le 23/05/11 21:41, Paulo Panhoto a écrit :
> >
> > Hello,
> >
> > I'm writing a Qt app with libssh. The best approach I've got
> > was this:
> > wrap ssh in a QThread that emits signals to other components.
> >
> >
> > session = ssh_new();
> >
> > if (session == NULL)
> > {
> > throw SSHException(tr("ssh_new failed"));
> > }
> > const std::string & stdHost = host.toStdString();
> > ssh_options_set(session, SSH_OPTIONS_HOST,
> > stdHost.c_str());
> > ssh_options_set(session, SSH_OPTIONS_PORT, &port);
> > ssh_options_set(session, SSH_OPTIONS_SSH1,
> &disabled);
> > ssh_options_set(session, SSH_OPTIONS_SSH2, &enabled);
> >
> > emit stateChanged(CONNECTING);
> > emit debugInfo(tr("Conecting to
> > %0:%1").arg(host).arg(port));
> > if (ssh_connect(session) != SSH_OK)
> > {
> > throw SSHException(QString("ssh_connect:
> > %1").arg(ssh_get_error(session)));
> > }
> >
> > This piece of code is causing me trouble: I'm running it on
> > a opensuse
> > 11.3 and tested it with libssh 0.4.2 (the "branding"
> > release) and 0.4.8.
> >
> > When I compile it against OpenSSL, I get aborts due to
> >
Re. Can't find libssh_threads_pthread
Hi Ivan, > "However, you must be sure to link with the library ssh_threads_pthread. If > you're using gcc, you must use the commandline > gcc -o output input.c -lssh -lssh_threads_pthread" > I tryed to install libssh from debian repository and compile from sources. > Anyway, I just can't find this library. > So were it should be? > Thank you very much! I just ran into the same problem and came up with your post in the archives but no reply. Just figured out how to resolve this and thought I'd reply back in case someone else runs into this. Apparently as shown in tests/unittests/torture_rand.c the correct way is to use ssh_threads_set_callbacks(ssh_threads_get_pthread()); and link with the libssh_threads library Hope this helps. Bye for now. Jeetu eBrain.in | Beehive Computing Discover and Run software from any device near you - an open source (gpl) initiative
Re: libssh 0.5 released
congrats guysgreat work and thanks :) On Wed, Jun 1, 2011 at 4:51 PM, Aris Adamantiadis wrote: > _ _ _ _ > (_) (_) (_) (_) > (_) _ (_) _ _ _ _ _ (_) _ > (_) (_) (_)(_) _ (_)(_) (_)(_) (_)(_) _ > (_) (_) (_) (_) _ (_) _ (_) (_) (_) > (_) (_) (_)(_)(_) (_)(_) (_)(_) (_) (_).org > > We are proud to finally announce libssh in version 0.5. It took a lot of > time to get this version stable and out. We have rewritten huge parts of > the libssh internals to be able to be completely async in future. The > whole network design passed from synchronous calls to an event-based > asynchronous system. We also welcomed Milo as a new developer in our > team. He is working on the server support and ssh_pki, which will > provide a complete API to manipulate SSH keys. We also have to thank > Oliver Stöneberg who tested 0.5 over the last months and sent a big > amount of patches, and Eric Bischoff who authored many pages of the > tutorial. > > If you are new to libssh read The Tutorial[1] how to get started. Please > join our mailing list[2] or visit our irc channel[3] if you have questions. > > You can download libssh 0.5.0 here[4]. For Windows binaries we suggest > to use our MSVC build [5] or the MSVC and MinGW binaries from the KDE > Windows project here [6]. Packages for Fedora and for openSUSE are > available here [7]. > > For the libssh team, > > Aris > > ChangeLog: > > Added ssh_ prefix to all public functions. > Added complete Windows support. > Added improved server support. > Added unit tests for a lot of functions. > Added asynchronous service request. > Added a multiplatform ssh_getpass() function. > Added a tutorial. > Added a lot of documentation. > Fixed a lot of bugs. > Fixed several memory leaks. > > > [1] http://api.libssh.org/master/libssh_tutorial.html > [2] http://www.libssh.org/communication/ > [3] irc://irc.freenode.net/libssh > [4] http://www.libssh.org/files/0.5/libssh-0.5.0.tar.gz > [5] http://www.libssh.org/files/win32/0.5/ > [6] http://winkde.org/pub/kde/ports/win32/ > [7] > http://download.opensuse.org/repositories/network:/synchronization:/files/ > >
multithreaded server issues
Hi guys,
I'm facing some issues with the libssh server that I'm putting
together. I'm using the latest libssh from the master. My code can be
found on pastebin at the link below. Also pasted below is the crash
report and what gdb has to about this.
The problem and how to reproduce:
If I make multiple X forwarding connections, and say x forward xeyes
and xcalc I get both the applications. Now if I simply just take one
of these windows and keep moving them around, I get a crash with the
following output.
This crash happens under other circumstances too but the above is a
sureshot way to trigger it.
To go through the server code:
Main thread :
- I am using gthreads for the threading and initialize gthread, call
ssh_threads_set_callbacks, ssh_init()
- I have a global ssh_session* (ssh_session is pointer to a pointer)
and I initiate this with a ssh_new (assuming this would allocate
memory).
- my ssh_bind and ssh_bind_listen is common for all ssh_sessions.
- I then enter a loop where I allocate a new
ssh_session[session_count] = ssh_new i.e. a new session, and move to
ssh_bind_accept (sshbind is common for all sessions, is this a
problem?)
- then public key authentication
- then i start a new thread and pass along session[session_count],
increment session_count.
- The server_thread sees which requests are coming along and calls
appropriate functions to open new channels or exec stuff.
- If SSH_CHANNEL_REQUEST_X11 is received it goes about setting up x11
forwarding, setting the x auth cookie, creating a port e.g. 6010 for
xclients to connect to, and listening for these connections on the
sockets.
- when a client connects to this socket, then I start a new thread
(wait_for_something function) and there is a select and if select goes
through then I accept() and get a client_socket.
- I then go about opening an x11 channel with ssh_channel_open_x11
*these are steps I'm thinking maybe causing the crash*
- wait for something thread has as a local variable the following
callback struct, since this is local and in a separate thread I'm
hoping this ensures that each thread / connection basically has it's
own callback and access to functions like copy_chan_to_fd etc and this
alone ensures that no threads or apps are overwriting/corrupting data.
is that correct?
struct ssh_channel_callbacks_struct cb =
{
.channel_data_function = copy_chan_to_fd,
.channel_eof_function = chan_close,
.channel_close_function = chan_close,
.userdata = NULL
};
- I then do a :
ssh_callbacks_init(&cb);
ssh_set_channel_callbacks(chan_x11, &cb);
events = POLLIN | POLLPRI | POLLERR | POLLHUP | POLLNVAL;
event = ssh_event_new();
- and after adding events, fd, etc as shown in samplesshd-tty.c i go
into a ssh_event_dopoll loop.
am not confident about my call back structures and if there is
some kind of thread issues being caused there.am not using mutexes
here and I've experimented with them but not sure where in the code I
need them (mutexes I've experimented with are in comments).
Could definitely use any help.
Sorry for the large descript and offloading a rather arduous task to
you guys..am just not sure if this is an issue with my code (most
likely) or libssh threading issue?.or if someone could help me
decipher what the gdb bt below is trying to tell me would appreciate
it :)...any pointers would be great pls.
Bye for now
--
Server code:
http://pastebin.com/F8Mbgzh2
compile with:
gcc -g -Wall -Wstrict-prototypes -O0 -o ebpsshd
-I/home/jeetu/utils/libssh/libssh-project/include
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include/ ebpsshd.c
-L/home/jeetu/utils/libssh/libssh-project/build/src -lssh
-L/home/jeetu/utils/libssh/libssh-project/build/src/threads
-lssh_threads -lglib-2.0 -lgthread-2.0
---
*** glibc detected *** /home/jeetu/code/misc/ebpsshd: double free or
corruption (!prev): 0x0061a8b0 ***
=== Backtrace: =
/lib/libc.so.6(+0x71ad6)[0x771acad6]
/lib/libc.so.6(+0x77563)[0x771b2563]
/lib/libc.so.6(realloc+0xf0)[0x771b2a00]
/home/jeetu/utils/libssh/libssh-project/build/src/libssh.so.4(+0x11591)[0x77b9c591]
/home/jeetu/utils/libssh/libssh-project/build/src/libssh.so.4(+0x116ff)[0x77b9c6ff]
/home/jeetu/utils/libssh/libssh-project/build/src/libssh.so.4(+0x3676e)[0x77bc176e]
/home/jeetu/utils/libssh/libssh-project/build/src/libssh.so.4(+0x2feff)[0x77bbaeff]
/home/jeetu/utils/libssh/libssh-project/build/src/libssh.so.4(+0x30300)[0x77bbb300]
/home/jeetu/utils/libssh/libssh-project/build/src/libssh.so.4(+0x303cf)[0x77bbb3cf]
/home/jeetu/utils/libssh/libssh-project/build/src/libssh.so.4(+0x155a6)[0x77ba05a6]
/home/jeetu/utils/libssh/libssh
Re: multithreaded server issues
Hi again,
I've made further progress in my attempts to debug my server code.
I've increased the buffer size in copy_fd_to_chan from 4000 to 4
and am reading slightly less than that. I also noticed that I had not
initialized the buffer.
Result:
The apps launched seem to be far more stable, even with 3 concurrent
connections :) I did have a crash after a lot of use - will study this
some more.
However this gives credence to my thought that it is something wrong
in my code (and/or my understanding so far) than libssh itself.
A question running though my mind yet though is if I should have
mutexes before reading from fd and then again while writing to the
channel or since each connection is a separate session and thread it
doesn't matter.
Thanks again for everything, any thoughts on any of the above and
general pointers on things I should be keeping in mind based on your
own experience would be appreciated.
Bye for now
On Sat, Jun 4, 2011 at 2:32 PM, jeetu.gol...@gmail.com
wrote:
> Hi guys,
>
> I'm facing some issues with the libssh server that I'm putting
> together. I'm using the latest libssh from the master. My code can be
> found on pastebin at the link below. Also pasted below is the crash
> report and what gdb has to about this.
>
> The problem and how to reproduce:
>
> If I make multiple X forwarding connections, and say x forward xeyes
> and xcalc I get both the applications. Now if I simply just take one
> of these windows and keep moving them around, I get a crash with the
> following output.
>
> This crash happens under other circumstances too but the above is a
> sureshot way to trigger it.
>
> To go through the server code:
>
> Main thread :
>
> - I am using gthreads for the threading and initialize gthread, call
> ssh_threads_set_callbacks, ssh_init()
>
> - I have a global ssh_session* (ssh_session is pointer to a pointer)
> and I initiate this with a ssh_new (assuming this would allocate
> memory).
>
> - my ssh_bind and ssh_bind_listen is common for all ssh_sessions.
>
> - I then enter a loop where I allocate a new
> ssh_session[session_count] = ssh_new i.e. a new session, and move to
> ssh_bind_accept (sshbind is common for all sessions, is this a
> problem?)
>
> - then public key authentication
>
> - then i start a new thread and pass along session[session_count],
> increment session_count.
>
> - The server_thread sees which requests are coming along and calls
> appropriate functions to open new channels or exec stuff.
>
> - If SSH_CHANNEL_REQUEST_X11 is received it goes about setting up x11
> forwarding, setting the x auth cookie, creating a port e.g. 6010 for
> xclients to connect to, and listening for these connections on the
> sockets.
>
> - when a client connects to this socket, then I start a new thread
> (wait_for_something function) and there is a select and if select goes
> through then I accept() and get a client_socket.
>
> - I then go about opening an x11 channel with ssh_channel_open_x11
>
> *these are steps I'm thinking maybe causing the crash*
>
> - wait for something thread has as a local variable the following
> callback struct, since this is local and in a separate thread I'm
> hoping this ensures that each thread / connection basically has it's
> own callback and access to functions like copy_chan_to_fd etc and this
> alone ensures that no threads or apps are overwriting/corrupting data.
> is that correct?
>
> struct ssh_channel_callbacks_struct cb =
> {
> .channel_data_function = copy_chan_to_fd,
> .channel_eof_function = chan_close,
> .channel_close_function = chan_close,
> .userdata = NULL
> };
>
> - I then do a :
>
> ssh_callbacks_init(&cb);
> ssh_set_channel_callbacks(chan_x11, &cb);
> events = POLLIN | POLLPRI | POLLERR | POLLHUP | POLLNVAL;
> event = ssh_event_new();
>
> - and after adding events, fd, etc as shown in samplesshd-tty.c i go
> into a ssh_event_dopoll loop.
>
> am not confident about my call back structures and if there is
> some kind of thread issues being caused there.am not using mutexes
> here and I've experimented with them but not sure where in the code I
> need them (mutexes I've experimented with are in comments).
>
> Could definitely use any help.
>
> Sorry for the large descript and offloading a rather arduous task to
> you guys..am just not sure if this is an issue with my code (most
> likely) or libssh threading issue?.or if someone could help me
> decipher what the gdb bt below is trying to tell me would appreciate
> it :)...any pointers would be great pls.
>
> Bye for now
>
> ---
HMAC error - help pls
Hi guys, In continuation with my efforts to put together a libssh based server, I have had significant success and can say it is very impressive to see the effort you guys have put in the libssh library, thank you :) I could sincerely use some help though. All in all my server is behaving much more robust than it ever has. I have been testing with multiple X client applications being forwarded simultaneously and all in all it runs well. I had some previous issues I had mailed this list about (subject: multithreaded server issues) but an init of the buffer seems to have helped. I have noticed some behaviour I do not understand. Below is what the libssh log says when set to SSH_LOG_PACKET With multiple applications, after extensive use of the applications (for e.g. xeyes and xclock running) I have noticed that after sometime the applications are unable to refresh their window - there is no crash most of these times and if left alone maybe clock may eventually refresh part of the window etc. xeyes stops showing it's eyes moving around but still seems to be running - ssh client connected seems to show some activity too. The libssh log seems to suggest that there is packet corruption at this point. Two things stand out from the below log: I] [3] Decrypting 16 bytes [3] Packet size decrypted: 2754678753 (0xa4310fe1) [1] Error : read_packet(): Packet len too high(2754678753 a4310fe1) II] [3] Decrypting 96 bytes [1] Error : HMAC error Pls note this log is an excerpt of a long log taken once the strange behaviour has manifested. What is a HMAC error? can someone pls shed light on what could be causing the above? Thanks, Jeetu [3] Type 94 [3] Dispatching handler for packet type 94 [2] Channel receiving 32 bytes data in 0 (local win=72640 remote win=2095160) [1] placing 32 bytes into channel buffer (stderr=0) [2] Channel windows are now (local win=72608 remote win=2095160) [3] Decrypting 16 bytes [3] Packet size decrypted: 60 (0x3c) [3] Read a 60 bytes packet [3] Decrypting 48 bytes [3] 18 bytes padding, 59 bytes left in buffer [3] After padding, 41 bytes left in buffer [3] Final size 41 [3] Type 94 [3] Dispatching handler for packet type 94 [2] Channel receiving 32 bytes data in 0 (local win=72608 remote win=2095160) [1] placing 32 bytes into channel buffer (stderr=0) [2] Channel windows are now (local win=72576 remote win=2095160) [3] Decrypting 16 bytes [3] Decrypting 16 bytes [3] Packet size decrypted: 2754678753 (0xa4310fe1) [1] Error : read_packet(): Packet len too high(2754678753 a4310fe1) [3] Packet size decrypted: 92 (0x5c) [3] Read a 92 bytes packet [3] Decrypting 96 bytes [1] Error : HMAC error [3] Writing on the wire a packet having 1993 bytes before [3] 1993 bytes after comp + 18 padding bytes = 2012 bytes packet [3] Encrypting packet with seq num: 36518, len: 2016 [3] Enabling POLLOUT for socket [1] channel_write wrote 1984 bytes [3] Writing on the wire a packet having 17 bytes before [3] 17 bytes after comp + 10 padding bytes = 28 bytes packet [3] Encrypting packet with seq num: 36519, len: 32 [3] Enabling POLLOUT for socket [1] channel_write wrote 8 bytes [3] Read a 92 bytes packet [3] Decrypting 176 bytes [1] Error : HMAC error [3] Read a 92 bytes packet [3] Decrypting 256 bytes [1] Error : HMAC error [3] Read a 92 bytes packet [3] Decrypting 336 bytes [1] Error : HMAC error [3] Read a 92 bytes packet [3] Decrypting 416 bytes [1] Error : HMAC error [3] Read a 92 bytes packet [3] Decrypting 496 bytes [1] Error : HMAC error [3] Read a 92 bytes packet [3] Decrypting 576 bytes [1] Error : HMAC error [3] Read a 92 bytes packet [3] Decrypting 656 bytes [1] Error : HMAC error [3] Read a 92 bytes packet [3] Decrypting 736 bytes [1] Error : HMAC error [3] Read a 92 bytes packet [3] Decrypting 816 bytes [1] Error : HMAC error [3] Read a 92 bytes packet [3] Decrypting 896 bytes [1] Error : HMAC error [3] Read a 92 bytes packet [3] Decrypting 976 bytes [1] Error : HMAC error [3] Read a 92 bytes packet [3] Decrypting 1056 bytes [1] Error : HMAC error [3] Read a 92 bytes packet [3] Decrypting 1136 bytes [1] Error : HMAC error [3] Read a 92 bytes packet [3] Decrypting 1216 bytes [1] Error : HMAC error [3] Read a 92 bytes packet [3] Decrypting 1296 bytes [1] Error : HMAC error [3] Read a 92 bytes packet [3] Decrypting 1376 bytes [1] Error : HMAC error [3] Writing on the wire a packet having 8605 bytes before [3] 8605 bytes after comp + 14 padding bytes = 8620 bytes packet [3] Encrypting packet with seq num: 885, len: 8624 [3] Enabling POLLOUT for socket [1] channel_write wrote 8596 bytes [3] Writing on the wire a packet having 8605 bytes before [3] 8605 bytes after comp + 14 padding bytes = 8620 bytes packet [3] Encrypting packet with seq num: 886, len: 8624 [3] Enabling POLLOUT for socket [1] channel_write wrote 8596 bytes [3] Decrypting 16 bytes [3] Packet size decrypted: 3661937450 (0xda44bb2a) [1] Error : read_packet(): Packet len too high(3661937450 da44bb2a)
Re: HMAC error - help pls
Hi Aris, Thanks for replying. Unfortunately I copy pasted only this part of the log, will reproduce the error and paste the entire log. As for an estimation on the amount of data, gauging that the packet number above is 36519 and while most packets seemed to have a length of 32bytes, I did see some packets with a length of 668bytes too (about 10%).am guessing approx 35 Megabytes of data. For the ssh client I am using a standard openssh client, the server is my own and creates a socket where an X client connects etc. Sincerely need your help. Thanks and sorry for the trouble. Bye for now On Tue, Jun 7, 2011 at 4:08 PM, Aris Adamantiadis wrote: > Hi Jeetu, > > I did not have much time to read your email completely, but it seems in > first impression that server/client is sending garbage. Could you attach > the first hundreds lines of debugging output, especially the key exchange ? > Also, do you have an estimation of the number of bytes that have been > transmitted before the failure ? (i.e. does it approach gigabytes ?) > > Thanks, > > Aris > > Le 7/06/11 12:00, jeetu.gol...@gmail.com a écrit : >> Hi guys, >> >> In continuation with my efforts to put together a libssh based server, >> I have had significant success and can say it is very impressive to >> see the effort you guys have put in the libssh library, thank you :) >> >> I could sincerely use some help though. All in all my server is >> behaving much more robust than it ever has. I have been testing with >> multiple X client applications being forwarded simultaneously and all >> in all it runs well. I had some previous issues I had mailed this list >> about (subject: multithreaded server issues) but an init of the buffer >> seems to have helped. >> >> I have noticed some behaviour I do not understand. Below is what the >> libssh log says when set to SSH_LOG_PACKET >> >> With multiple applications, after extensive use of the applications >> (for e.g. xeyes and xclock running) I have noticed that after sometime >> the applications are unable to refresh their window - there is no >> crash most of these times and if left alone maybe clock may eventually >> refresh part of the window etc. xeyes stops showing it's eyes moving >> around but still seems to be running - ssh client connected seems to >> show some activity too. >> >> The libssh log seems to suggest that there is packet corruption at >> this point. Two things stand out from the below log: >> >> I] >> >> [3] Decrypting 16 bytes >> [3] Packet size decrypted: 2754678753 (0xa4310fe1) >> [1] Error : read_packet(): Packet len too high(2754678753 a4310fe1) >> >> II] >> [3] Decrypting 96 bytes >> [1] Error : HMAC error >> >> Pls note this log is an excerpt of a long log taken once the strange >> behaviour has manifested. >> >> What is a HMAC error? can someone pls shed light on what could be >> causing the above? >> >> Thanks, >> Jeetu >> >> >> [3] Type 94 >> [3] Dispatching handler for packet type 94 >> [2] Channel receiving 32 bytes data in 0 (local win=72640 remote win=2095160) >> [1] placing 32 bytes into channel buffer (stderr=0) >> [2] Channel windows are now (local win=72608 remote win=2095160) >> [3] Decrypting 16 bytes >> [3] Packet size decrypted: 60 (0x3c) >> [3] Read a 60 bytes packet >> [3] Decrypting 48 bytes >> [3] 18 bytes padding, 59 bytes left in buffer >> [3] After padding, 41 bytes left in buffer >> [3] Final size 41 >> [3] Type 94 >> [3] Dispatching handler for packet type 94 >> [2] Channel receiving 32 bytes data in 0 (local win=72608 remote win=2095160) >> [1] placing 32 bytes into channel buffer (stderr=0) >> [2] Channel windows are now (local win=72576 remote win=2095160) >> [3] Decrypting 16 bytes >> [3] Decrypting 16 bytes >> [3] Packet size decrypted: 2754678753 (0xa4310fe1) >> [1] Error : read_packet(): Packet len too high(2754678753 a4310fe1) >> [3] Packet size decrypted: 92 (0x5c) >> [3] Read a 92 bytes packet >> [3] Decrypting 96 bytes >> [1] Error : HMAC error >> [3] Writing on the wire a packet having 1993 bytes before >> [3] 1993 bytes after comp + 18 padding bytes = 2012 bytes packet >> [3] Encrypting packet with seq num: 36518, len: 2016 >> [3] Enabling POLLOUT for socket >> [1] channel_write wrote 1984 bytes >> [3] Writing on the wire a packet having 17 bytes before >> [3] 17 bytes after comp + 10 padding bytes = 28 bytes packet >> [3] Encrypting packet with seq num: 36519, len: 32 >> [3] Enabling POLLOUT for socket >> [1] c
Re: HMAC error - help pls
Hi Aris, First, I'm extremely sorry for not following up on your previous mail - unfortunately things have been a little too chaotic. Thank you so much for taking the time to look into this, I truly and profusely appreciate it and will work with you and help as much as I can in ruling out libssh as the culprit. Of course I'm not too certain of what in my code could upset libssh and neither am I very confident of my own code at this point of time so may need to seek help from you - pls bare with me :) I have managed to reproduce this behaviour and collect some data.will go through it and report back.I want to see mainly if there is the Decrypting 16 bytes occurring one after the other this time around too. Bye for now On Thu, Jun 9, 2011 at 2:38 PM, Aris Adamantiadis wrote: > Hi, > > I have inspected the code path, there is no possibility for "decrypting > 16 bytes" message to show up twice in a row. Are you using several > sessions ? If so, could you try again but with only one client ? I'm not > yet sure it's not a libssh problem so I prefer we investigate. > > Kr, > > Aris > > Le 7/06/11 13:22, jeetu.gol...@gmail.com a écrit : >> Hi Aris, >> >> Thanks for replying. >> >> Unfortunately I copy pasted only this part of the log, will reproduce >> the error and paste the entire log. >> >> As for an estimation on the amount of data, gauging that the packet >> number above is 36519 and while most packets seemed to have a length >> of 32bytes, I did see some packets with a length of 668bytes too >> (about 10%).am guessing approx 35 Megabytes of data. >> >> For the ssh client I am using a standard openssh client, the server is >> my own and creates a socket where an X client connects etc. >> >> Sincerely need your help. Thanks and sorry for the trouble. >> >> Bye for now >> >> On Tue, Jun 7, 2011 at 4:08 PM, Aris Adamantiadis wrote: >>> Hi Jeetu, >>> >>> I did not have much time to read your email completely, but it seems in >>> first impression that server/client is sending garbage. Could you attach >>> the first hundreds lines of debugging output, especially the key exchange ? >>> Also, do you have an estimation of the number of bytes that have been >>> transmitted before the failure ? (i.e. does it approach gigabytes ?) >>> >>> Thanks, >>> >>> Aris >>> >>> Le 7/06/11 12:00, jeetu.gol...@gmail.com a écrit : >>>> Hi guys, >>>> >>>> In continuation with my efforts to put together a libssh based server, >>>> I have had significant success and can say it is very impressive to >>>> see the effort you guys have put in the libssh library, thank you :) >>>> >>>> I could sincerely use some help though. All in all my server is >>>> behaving much more robust than it ever has. I have been testing with >>>> multiple X client applications being forwarded simultaneously and all >>>> in all it runs well. I had some previous issues I had mailed this list >>>> about (subject: multithreaded server issues) but an init of the buffer >>>> seems to have helped. >>>> >>>> I have noticed some behaviour I do not understand. Below is what the >>>> libssh log says when set to SSH_LOG_PACKET >>>> >>>> With multiple applications, after extensive use of the applications >>>> (for e.g. xeyes and xclock running) I have noticed that after sometime >>>> the applications are unable to refresh their window - there is no >>>> crash most of these times and if left alone maybe clock may eventually >>>> refresh part of the window etc. xeyes stops showing it's eyes moving >>>> around but still seems to be running - ssh client connected seems to >>>> show some activity too. >>>> >>>> The libssh log seems to suggest that there is packet corruption at >>>> this point. Two things stand out from the below log: >>>> >>>> I] >>>> >>>> [3] Decrypting 16 bytes >>>> [3] Packet size decrypted: 2754678753 (0xa4310fe1) >>>> [1] Error : read_packet(): Packet len too high(2754678753 a4310fe1) >>>> >>>> II] >>>> [3] Decrypting 96 bytes >>>> [1] Error : HMAC error >>>> >>>> Pls note this log is an excerpt of a long log taken once the strange >>>> behaviour has manifested. >>>> >>>> What is a HMAC error? can someone pls shed light on what could be >>>>
Re: HMAC error - help pls
Hi Aris,
I'm still collecting more debugging information. I noticed that while
this behaviour is reproducible each time it doesn't always throw out
the HMAC error, I'm still trying to verify all of this.
In the mean time could you please verify if prima facie the logic i'm
using to code the server below makes sense to you and/or something
there could be causing this error. I had pasted this portion in a
previous thread to the list too.
Thanks so much, will get back with more data and after I review all
you've asked me in previous mails
Bye for now
--
To go through the server code:
Main thread :
- I am using gthreads for the threading and initialize gthread, call
ssh_threads_set_callbacks, ssh_init()
- I have a global ssh_session* (ssh_session is pointer to a pointer)
and I initiate this with a ssh_new (assuming this would allocate
memory).
- my ssh_bind and ssh_bind_listen is common for all ssh_sessions.
- I then enter a loop where I allocate a new
ssh_session[session_count] = ssh_new i.e. a new session, and move to
ssh_bind_accept (sshbind is common for all sessions, is this a
problem?)
- then public key authentication
- then i start a new thread and pass along session[session_count],
increment session_count.
- The server_thread sees which requests are coming along and calls
appropriate functions to open new channels or exec stuff.
- If SSH_CHANNEL_REQUEST_X11 is received it goes about setting up x11
forwarding, setting the x auth cookie, creating a port e.g. 6010 for
xclients to connect to, and listening for these connections on the
sockets.
- when a client connects to this socket, then I start a new thread
(wait_for_something function) and there is a select and if select goes
through then I accept() and get a client_socket.
- I then go about opening an x11 channel with ssh_channel_open_x11
*these are steps I'm thinking maybe causing the crash*
- wait for something thread has as a local variable the following
callback struct, since this is local and in a separate thread I'm
hoping this ensures that each thread / connection basically has it's
own callback and access to functions like copy_chan_to_fd etc and this
alone ensures that no threads or apps are overwriting/corrupting data.
is that correct?
struct ssh_channel_callbacks_struct cb =
{
.channel_data_function = copy_chan_to_fd,
.channel_eof_function = chan_close,
.channel_close_function = chan_close,
.userdata = NULL
};
- I then do a :
ssh_callbacks_init(&cb);
ssh_set_channel_callbacks(chan_x11, &cb);
events = POLLIN | POLLPRI | POLLERR | POLLHUP | POLLNVAL;
event = ssh_event_new();
- and after adding events, fd, etc as shown in samplesshd-tty.c i go
into a ssh_event_dopoll loop.
am not confident about my call back structures and if there is
some kind of thread issues being caused there.am not using mutexes
here and I've experimented with them but not sure where in the code I
need them (mutexes I've experimented with are in comments).
---
On Thu, Jun 9, 2011 at 2:51 PM, jeetu.gol...@gmail.com
wrote:
> Hi Aris,
>
> First, I'm extremely sorry for not following up on your previous mail
> - unfortunately things have been a little too chaotic.
>
> Thank you so much for taking the time to look into this, I truly and
> profusely appreciate it and will work with you and help as much as I
> can in ruling out libssh as the culprit. Of course I'm not too certain
> of what in my code could upset libssh and neither am I very confident
> of my own code at this point of time so may need to seek help from you
> - pls bare with me :)
>
> I have managed to reproduce this behaviour and collect some
> data.will go through it and report back.I want to see mainly
> if there is the Decrypting 16 bytes occurring one after the other this
> time around too.
>
> Bye for now
>
> On Thu, Jun 9, 2011 at 2:38 PM, Aris Adamantiadis wrote:
>> Hi,
>>
>> I have inspected the code path, there is no possibility for "decrypting
>> 16 bytes" message to show up twice in a row. Are you using several
>> sessions ? If so, could you try again but with only one client ? I'm not
>> yet sure it's not a libssh problem so I prefer we investigate.
>>
>> Kr,
>>
>> Aris
>>
>> Le 7/06/11 13:22, jeetu.gol...@gmail.com a écrit :
>>> Hi Aris,
>>>
>>> Thanks for replying.
>>>
>>> Unfortunately I copy pasted only this part of the log, will reproduce
>>> the error and paste the entire log.
>>>
>>
Re: HMAC error - help pls
Hi Aris, > symptom of garbage in the decrypted packets, in fact I changed things in > master to have it throw an error as soon as the packet size looks buggy. read_packet apparently is complaining that that packet size is too long in the ssh_log outputs I sent across with my tests using only a single client. Any way you can think of that I can rule out that this error reported by read_packet isn't being caused somehow by my code? > I'll add an info in the ssh_log call to have the session uniquely > identified, it will be easier to track down then. Yes this would definitely make it easier to debug. Please let me know any steps you think I should follow to narrow down our scope as to where the problem lies. Thanks a lot for looking into this Aris :) Bye for now On Wed, Jun 15, 2011 at 2:24 PM, Aris Adamantiadis wrote: > Hi Jeetu, > > I did not have the occasion to look futher. The HMAC error is simply a > symptom of garbage in the decrypted packets, in fact I changed things in > master to have it throw an error as soon as the packet size looks buggy. > I'll add an info in the ssh_log call to have the session uniquely > identified, it will be easier to track down then. > Kr, > > Aris > > Le 11/06/11 13:37, jeetu.gol...@gmail.com a écrit : >> Hi Aris, >> >> I had a memory allocation doubt in my code, basically a memory >> allocation/instantiation doubt in the ssh_session with the following >> logic: >> >> - >> - I have a global ssh_session* (ssh_session is pointer to a pointer) >> and I initiate this with a ssh_new (assuming this would allocate >> memory). >> >> - my ssh_bind and ssh_bind_listen is common for all ssh_sessions. >> >> - I then enter a loop where I allocate a new >> ssh_session[session_count] = ssh_new i.e. a new session, and move to >> ssh_bind_accept (sshbind is common for all sessions, is this a >> problem?) >> >> - upon authentication >> - >> >> I have just tried replacing the above logic with a fixed array of >> ssh_session and simply >> instantiating it in the loop with a session[server_count] = ssh_new() >> and upon authorization >> I spawn a new thread that handles channel requests,etc >> >> I am also testing with just a single connect from ssh client. >> >> Unfortunately I still see the phenomena wherein the window soon loses >> ability to refresh itself. >> I am attaching the ssh log debugging output but the critical section >> is as follows wherein >> read_packet says that packet len too high. >> >> In none of the tests where I launch just a single ssh client to >> connect do I get a HMAC error. >> In a couple of tests I have done launching multiple sessions produces >> this effect but with the >> same read_packet error as below but no HMAC error. >> >> I'm attaching the full debug output of this current test. Pls let me >> know your thoughts. >> >> Decrypting 16 bytes >> [3] Packet size decrypted: 60 (0x3c) >> [3] Read a 60 bytes packet >> [3] Decrypting 48 bytes >> [3] 18 bytes padding, 59 bytes left in buffer >> [3] After padding, 41 bytes left in buffer >> [3] Final size 41 >> [3] Type 94 >> [3] Dispatching handler for packet type 94 >> [2] Channel receiving 32 bytes data in 0 (local win=113716 remote >> win=2097152) >> [1] placing 32 bytes into channel buffer (stderr=0) >> [2] Channel windows are now (local win=113684 remote win=2097152) >> [3] Decrypting 16 bytes >> [3] Packet size decrypted: 597749705 (0x23a0efc9) >> [1] Error : read_packet(): Packet len too high(597749705 23a0efc9) >> [3] Decrypting 16 bytes >> [3] Packet size decrypted: 4194306560 (0xfa000a00) >> [1] Error : read_packet(): Packet len too high(4194306560 fa000a00) >> >> Bye for now >> >> >> On Fri, Jun 10, 2011 at 12:00 AM, jeetu.gol...@gmail.com >> wrote: >>> Hi Aris, >>> >>>>>> sessions ? If so, could you try again but with only one client ? I'm not >>>>>> yet sure it's not a libssh problem so I prefer we investigate. >>> >>> I ran a couple of tests with just a single ssh client connecting in. >>> Once I ran xeyes >>> and the next i ran xclock. Both applications failed when i kept moving >>> the windows >>> vigarously. >>> >>> The server has spewed out that both these times it was because >>> read_packet reported >>> that packet length was too large. This is something that if memory >>> serves me right we >
Re: HMAC error - help pls
Hi Aris, How're u doing? Just wanted to know if you could recommend places in either my code or libssh that may give us some clues as to what is causing this behaviour.I may not understand libssh internals as well but maybe you could give me some pointers and I could collect data and that may make it easier to figure this out. Again I realize you guys are probably extremely tied up and am hoping if you show me the way I can help in some small way. Thanks so much :) Bye for now On Wed, Jun 15, 2011 at 3:01 PM, jeetu.gol...@gmail.com wrote: > Hi Aris, > >> symptom of garbage in the decrypted packets, in fact I changed things in >> master to have it throw an error as soon as the packet size looks buggy. > > read_packet apparently is complaining that that packet size is too long in > the ssh_log outputs I sent across with my tests using only a single client. > Any way you can think of that I can rule out that this error reported by > read_packet isn't being caused somehow by my code? > >> I'll add an info in the ssh_log call to have the session uniquely >> identified, it will be easier to track down then. > > Yes this would definitely make it easier to debug. > > Please let me know any steps you think I should follow to narrow down > our scope as to where the problem lies. > > Thanks a lot for looking into this Aris :) > > Bye for now > > > > > On Wed, Jun 15, 2011 at 2:24 PM, Aris Adamantiadis wrote: >> Hi Jeetu, >> >> I did not have the occasion to look futher. The HMAC error is simply a >> symptom of garbage in the decrypted packets, in fact I changed things in >> master to have it throw an error as soon as the packet size looks buggy. >> I'll add an info in the ssh_log call to have the session uniquely >> identified, it will be easier to track down then. >> Kr, >> >> Aris >> >> Le 11/06/11 13:37, jeetu.gol...@gmail.com a écrit : >>> Hi Aris, >>> >>> I had a memory allocation doubt in my code, basically a memory >>> allocation/instantiation doubt in the ssh_session with the following >>> logic: >>> >>> - >>> - I have a global ssh_session* (ssh_session is pointer to a pointer) >>> and I initiate this with a ssh_new (assuming this would allocate >>> memory). >>> >>> - my ssh_bind and ssh_bind_listen is common for all ssh_sessions. >>> >>> - I then enter a loop where I allocate a new >>> ssh_session[session_count] = ssh_new i.e. a new session, and move to >>> ssh_bind_accept (sshbind is common for all sessions, is this a >>> problem?) >>> >>> - upon authentication >>> - >>> >>> I have just tried replacing the above logic with a fixed array of >>> ssh_session and simply >>> instantiating it in the loop with a session[server_count] = ssh_new() >>> and upon authorization >>> I spawn a new thread that handles channel requests,etc >>> >>> I am also testing with just a single connect from ssh client. >>> >>> Unfortunately I still see the phenomena wherein the window soon loses >>> ability to refresh itself. >>> I am attaching the ssh log debugging output but the critical section >>> is as follows wherein >>> read_packet says that packet len too high. >>> >>> In none of the tests where I launch just a single ssh client to >>> connect do I get a HMAC error. >>> In a couple of tests I have done launching multiple sessions produces >>> this effect but with the >>> same read_packet error as below but no HMAC error. >>> >>> I'm attaching the full debug output of this current test. Pls let me >>> know your thoughts. >>> >>> Decrypting 16 bytes >>> [3] Packet size decrypted: 60 (0x3c) >>> [3] Read a 60 bytes packet >>> [3] Decrypting 48 bytes >>> [3] 18 bytes padding, 59 bytes left in buffer >>> [3] After padding, 41 bytes left in buffer >>> [3] Final size 41 >>> [3] Type 94 >>> [3] Dispatching handler for packet type 94 >>> [2] Channel receiving 32 bytes data in 0 (local win=113716 remote >>> win=2097152) >>> [1] placing 32 bytes into channel buffer (stderr=0) >>> [2] Channel windows are now (local win=113684 remote win=2097152) >>> [3] Decrypting 16 bytes >>> [3] Packet size decrypted: 597749705 (0x23a0efc9) >>> [1] Error : read_packet(): Packet len too high(597749705 23a0efc9) >>> [3] Decrypting 16 bytes >>> [3] Packet size decry
Attending the CCC?
Hey guys, Hope all well, it's been long. Is anyone here planning to attend the ccc? (http://events.ccc.de/camp/2011/) My friend Erle and I are going to attend, if you're there then it will be absolutely awesome to meet up :) We also plan to be traveling through Prague and Amsterdam later. Let me know if anyone here will be there and if we can catch up :) Bye for now ebrain.in | Beehive Computing Discover and run software from any device around you - an open source (GPL) project
seg fault trying libssh server examples
Hi guys, I've just been trying the latest libssh from master. I noticed that the server I've been working on kept dying with a Segmentation fault. I thought it was my code and deduced that things crash when I call ssh_handle_key_exchange(). I then tried the libssh examples built along with the library thinking I must be doing something wrong and once I verify the code in the examples works I'll learn from them and debug my code. However the server examples samplesshd and samplesshd-tty seem to seg fault too. Both of them use the same function i.e. ssh_handle_key_exchange(). Just to be sure I've tried it on two of my systems though both are running debian 64 bit. Is anyone else seeing this? Thanks for the help. Bye for now Jeetu ebrain.in | Beehive Computing Discover and run software from any device around you - an open source (GPL) project
Re: seg fault trying libssh server examples
Hi Aris, Thanks for looking into this. I'll give the release code a whirl probably after verifying if there are any fresh updates with the master. I'm interested to see if the problems I was seeing with the server code earlier - i.e. the strange HMAC errors and also X forwarding sometimes (about 20-30% of the time) mysteriously not working - still persist or have somehow gotten resolved. I'm still not clear if these were because of libssh or something in my code. Thanks again. Bye for now Jeetu ebrain.in | Beehive Computing Discover and run software from any device around you - an open source (GPL) project. On Thu, Sep 15, 2011 at 11:14 PM, Aris Adamantiadis wrote: > Hi Jeetu, > > Indeed, master server is broken. This is due to the implementation of ecdh > in the client, which is not yet present in server code right now. I'll work > on this this end of week. > Meanwhile, I suggest you use the latest libssh release which seemed to work. > > Aris > > Le 14/09/11 20:20, jeetu.gol...@gmail.com a écrit : >> >> Hi guys, >> >> I've just been trying the latest libssh from master. I noticed that >> the server I've been working on kept dying with a Segmentation fault. >> I thought it was my code and deduced that things crash when I call >> ssh_handle_key_exchange(). I then tried the libssh examples built >> along with the library thinking I must be doing something wrong and >> once I verify the code in the examples works I'll learn from them and >> debug my code. However the server examples samplesshd and >> samplesshd-tty seem to seg fault too. Both of them use the same >> function i.e. ssh_handle_key_exchange(). >> >> Just to be sure I've tried it on two of my systems though both are >> running debian 64 bit. >> >> Is anyone else seeing this? >> >> Thanks for the help. >> >> Bye for now >> Jeetu >> ebrain.in | Beehive Computing >> Discover and run software from any device around you - an open source >> (GPL) project >> > >
Server woes
Hi guys, As a few of you would remember I've been trying to build a libssh based server. The primary features I've been interested in the server are SSH authentication and X forwarding along with multithreaded support. I've had mixed success with the implementation in the past as I have reported here. After a long break (was off to CCC and had other things I needed to clear up) I tried the new libssh master with my server code. I reimplemented my server code for it to work with a single session so as to try to minimize chances that multi-threading was somehow causing things to bungle up. My X forwaded application fails after some usage. The failure shows up with the application seemingly unable to refresh its window. I've collected log information from libssh with verbosity set to SSH_LOG_PACKET and put it up on pastebin - http://pastebin.com/XpNWggGv The interesting segment seems to be: ... [2011/10/13 17:26:00.712651, 2] Channel receiving 32 bytes data in 0 (local win=1159472 remote win=2078764) [2011/10/13 17:26:00.712687, 1] placing 32 bytes into channel buffer (stderr=0) [2011/10/13 17:26:00.712722, 2] Channel windows are now (local win=1159440 remote win=2078764) [2011/10/13 17:26:00.725785, 1] ssh_packet_socket_callback Error: read_packet(): Packet len too high(2488547759 945439af) [2011/10/13 17:26:00.725890, 1] ssh_packet_socket_callback Error: HMAC error [2011/10/13 17:26:00.744160, 3] Enabling POLLOUT for socket [2011/10/13 17:26:00.744218, 3] packet: wrote [len=380,padding=6,comp=373,payload=373] [2011/10/13 17:26:00.744233, 1] channel_write wrote 364 bytes [2011/10/13 17:26:17.172236, 1] Socket exception callback: 1 (0) [2011/10/13 17:26:17.172334, 1] ssh_socket_exception_callback Error: Socket error: Success This read_packet with a packet len that is too high with an HMAC error seems to be consistent with results I had earlier. I am at a complete loss as to whether this and similar errors I've seen are as a result of my code or a bug in libssh. If someone could offer me thoughts as to which elements in my code could possibly be causing this I could look into these elements and try and narrow things down a little. I would sincerely appreciate some help in trying to resolve this. Thanks, Jeetu
Re: Server woes - Bad packet length, corrupted MAC on input
Hi guys, Further to the HMAC error I've been seeing in my server implementation. I've also been noticing many scenarios wherein the OpenSSH client quits with either a "Bad packet length" or a "corrupted MAC on input" I'm not sure if all ties in to the HMAC errors somehow. >From what I can see these errors (including HMAC) seem to be basically speaking of the integrity/state of the packet. Am I correct in assuming that this seems to hint at a lower level problem within libssh during creating the packets, encrypting and/or decrypting the packets than the server code which would basically just be routing information from the X client to the channel and vice versa. The server code now handles only a single session and is no longer multithreading and handling multiple sessions. Thanks guys please let me know any thoughts. At this stage any suggestions would be deeply appreciated. Bye for now On Thu, Oct 13, 2011 at 7:04 PM, jeetu.gol...@gmail.com wrote: > Hi guys, > > As a few of you would remember I've been trying to build a libssh > based server. The primary features I've been interested in the server > are SSH authentication and X forwarding along with multithreaded > support. > > I've had mixed success with the implementation in the past as I have > reported here. After a long break (was off to CCC and had other things > I needed to clear up) I tried the new libssh master with my server > code. I reimplemented my server code for it to work with a single > session so as to try to minimize chances that multi-threading was > somehow causing things to bungle up. > > My X forwaded application fails after some usage. The failure shows up > with the application seemingly unable to refresh its window. I've > collected log information from libssh with verbosity set to > SSH_LOG_PACKET and put it up on pastebin - > http://pastebin.com/XpNWggGv > > The interesting segment seems to be: > > ... > [2011/10/13 17:26:00.712651, 2] Channel receiving 32 bytes data in 0 > (local win=1159472 remote win=2078764) > [2011/10/13 17:26:00.712687, 1] placing 32 bytes into channel buffer > (stderr=0) > [2011/10/13 17:26:00.712722, 2] Channel windows are now (local > win=1159440 remote win=2078764) > [2011/10/13 17:26:00.725785, 1] ssh_packet_socket_callback Error: > read_packet(): Packet len too high(2488547759 945439af) > [2011/10/13 17:26:00.725890, 1] ssh_packet_socket_callback Error: HMAC error > [2011/10/13 17:26:00.744160, 3] Enabling POLLOUT for socket > [2011/10/13 17:26:00.744218, 3] packet: wrote > [len=380,padding=6,comp=373,payload=373] > [2011/10/13 17:26:00.744233, 1] channel_write wrote 364 bytes > [2011/10/13 17:26:17.172236, 1] Socket exception callback: 1 (0) > [2011/10/13 17:26:17.172334, 1] ssh_socket_exception_callback Error: > Socket error: Success > > This read_packet with a packet len that is too high with an HMAC error > seems to be consistent with results I had earlier. > > I am at a complete loss as to whether this and similar errors I've > seen are as a result of my code or a bug in libssh. If someone could > offer me thoughts as to which elements in my code could possibly be > causing this I could look into these elements and try and narrow > things down a little. > > I would sincerely appreciate some help in trying to resolve this. > > Thanks, > Jeetu >
Re: Server woes - Bad packet length, corrupted MAC on input
Hi Stefan, > debug3: Incorrect RSA1 identifier > debug3: Could not load "/home/jeetu/.ssh/id_rsa" as a RSA1 public key > debug2: key_type_from_name: unknown key type '-BEGIN' I've noticed this message also when I connect to the OpenSSH server, however in that case I do password authentication and all works. Also if the keys were an issue then shouldn't authentication itself fail?here the auth goes through and I can use the X client sometimes for a decent amount of time before things fail. Thanks for taking a look at this. Bye for now On Tue, Oct 18, 2011 at 3:30 PM, wrote: > Hi all, > > debug3: Incorrect RSA1 identifier > debug3: Could not load "/home/jeetu/.ssh/id_rsa" as a RSA1 public key > debug2: key_type_from_name: unknown key type '-BEGIN' > > > On Tue, Oct 18, 2011 at 03:22:08PM +0500, jeetu.gol...@gmail.com wrote: >> Hi Aris, >> >> I've attached a log of the libssh server >> (log-1-ebpsshd-singlesession-18102011.txt) and the OpenSSH client >> (log-ssh-1-18102011.txt). > > Greetings > -- > Stefan Kuttler ==*== nc.netbeisser.de > >
Re: Server woes - Bad packet length, corrupted MAC on input
> This is not a problem and shouldn't cause invalid MAC errors. I'm on > travel so I'll look at the log when i'm back. Thanks so much Aris :) On Tue, Oct 18, 2011 at 5:52 PM, Aris Adamantiadis wrote: > Hi, > > This is not a problem and shouldn't cause invalid MAC errors. I'm on > travel so I'll look at the log when i'm back. > > Aris > > Le 18/10/11 12:30, u...@netbeisser.de a écrit : >> Hi all, >> >> debug3: Incorrect RSA1 identifier >> debug3: Could not load "/home/jeetu/.ssh/id_rsa" as a RSA1 public key >> debug2: key_type_from_name: unknown key type '-BEGIN' >> >> >> On Tue, Oct 18, 2011 at 03:22:08PM +0500, jeetu.gol...@gmail.com wrote: >>> Hi Aris, >>> >>> I've attached a log of the libssh server >>> (log-1-ebpsshd-singlesession-18102011.txt) and the OpenSSH client >>> (log-ssh-1-18102011.txt). >> >> Greetings >> -- >> Stefan Kuttler ==*== nc.netbeisser.de >> > >
Re: Server woes - Bad packet length, corrupted MAC on input
Hi Aris, > I think I'll need a proof-of-concept code to debug this. Would you mind > sharing your code, or it's not possible (too much integration with > existing code). No problem at all :) The code is an independent unit as of now since I wanted to make it work before I integrate it within my open source project (eBrainPool) I'll mail this out to you tomm (not on the machine with the code right now :) ) Thanks so much for looking into this.truly appreciate it :) Bye for now On Fri, Oct 21, 2011 at 7:26 PM, Aris Adamantiadis wrote: > Hi Jeetu, > > By seeing your logs, I understand this: > Both side have a hmac error. The openssh client sees it first, sends a > disconnect (that works), then there's the error in the libssh log. > > I think I'll need a proof-of-concept code to debug this. Would you mind > sharing your code, or it's not possible (too much integration with > existing code). > > If so, do you think I can reproduce the problem by "fixing" samplesshd > to make new X11 channels connection connect to the local X11 unix socket ? > > Thanks. > > Aris > > > Le 18/10/11 20:34, jeetu.gol...@gmail.com a écrit : >>> This is not a problem and shouldn't cause invalid MAC errors. I'm on >>> travel so I'll look at the log when i'm back. >> >> Thanks so much Aris :) >> >> On Tue, Oct 18, 2011 at 5:52 PM, Aris Adamantiadis wrote: >>> Hi, >>> >>> This is not a problem and shouldn't cause invalid MAC errors. I'm on >>> travel so I'll look at the log when i'm back. >>> >>> Aris >>> >>> Le 18/10/11 12:30, u...@netbeisser.de a écrit : >>>> Hi all, >>>> >>>> debug3: Incorrect RSA1 identifier >>>> debug3: Could not load "/home/jeetu/.ssh/id_rsa" as a RSA1 public key >>>> debug2: key_type_from_name: unknown key type '-BEGIN' >>>> >>>> >>>> On Tue, Oct 18, 2011 at 03:22:08PM +0500, jeetu.gol...@gmail.com wrote: >>>>> Hi Aris, >>>>> >>>>> I've attached a log of the libssh server >>>>> (log-1-ebpsshd-singlesession-18102011.txt) and the OpenSSH client >>>>> (log-ssh-1-18102011.txt). >>>> >>>> Greetings >>>> -- >>>> Stefan Kuttler ==*== nc.netbeisser.de >>>> >>> >>> >> > >
Re: Server woes - Bad packet length, corrupted MAC on input
Hi Aris, I'm attaching my proof of concept server code as.ebpsshd-singlesession.c has compile instructions at the beginning of the code. You will also need to generate a key.h file that holds the public key of the user who will be connecting to this server - this is tempoarary since as of now I'm not reading this info from an authorized_keys or something similar. Just create a key.h file in the same directory and put something like : #define MY_PUB_KEY "[YOUR PUBLIC KEY WITHIN THESE QUOTES]" Also as of now ebpsshd-singlesession listens in on port 2000. So ssh should connect to that port. I also have a libssh-project-wrapper script that allows me to try this out without needing to install the libssh i've built. It basically has the content: #!/bin/sh export LD_LIBRARY_PATH=/home/jeetu/utils/libssh/libssh-project/build/src:/home/jeetu/utils/libssh/libssh-project/build/src/threads ./$1 I have been testing this code with simple examples like xeyes and xcalc. For some reason xcalc shows the problem much sooner than with xeyes, maybe because of the volume of data being transmitted to and fro? This is proof of concept code with a lot of fiddling with buffer sizes as I have been trying to study if any of that makes an impact however please point out any way you think this can be improved on :) I'm sorry to drop this in your lap especially if it turns out it was some server side code issue, however I completely appreciate your help on this. I would like to squash this bug regardless of where it lies i.e. in my code or libssh, unfortunately my understanding of libssh and the ssh protocol is a little limited. However I do not want to put all of this load completely in your lap and if you share your thoughts and there's something you would like me to look into then please let me know. Thanks, Jeetu ebrain.in | Beehive Computing Discover and run software from any device around you - an open source (GPL) project. On Fri, Oct 21, 2011 at 11:22 PM, jeetu.gol...@gmail.com wrote: > Hi Aris, > >> I think I'll need a proof-of-concept code to debug this. Would you mind >> sharing your code, or it's not possible (too much integration with >> existing code). > > No problem at all :) The code is an independent unit as of now since I > wanted to make it work before I integrate it within my open source > project (eBrainPool) > > I'll mail this out to you tomm (not on the machine with the code right now :) > ) > > Thanks so much for looking into this.truly appreciate it :) > > Bye for now > > > On Fri, Oct 21, 2011 at 7:26 PM, Aris Adamantiadis wrote: >> Hi Jeetu, >> >> By seeing your logs, I understand this: >> Both side have a hmac error. The openssh client sees it first, sends a >> disconnect (that works), then there's the error in the libssh log. >> >> I think I'll need a proof-of-concept code to debug this. Would you mind >> sharing your code, or it's not possible (too much integration with >> existing code). >> >> If so, do you think I can reproduce the problem by "fixing" samplesshd >> to make new X11 channels connection connect to the local X11 unix socket ? >> >> Thanks. >> >> Aris >> >> >> Le 18/10/11 20:34, jeetu.gol...@gmail.com a écrit : >>>> This is not a problem and shouldn't cause invalid MAC errors. I'm on >>>> travel so I'll look at the log when i'm back. >>> >>> Thanks so much Aris :) >>> >>> On Tue, Oct 18, 2011 at 5:52 PM, Aris Adamantiadis >>> wrote: >>>> Hi, >>>> >>>> This is not a problem and shouldn't cause invalid MAC errors. I'm on >>>> travel so I'll look at the log when i'm back. >>>> >>>> Aris >>>> >>>> Le 18/10/11 12:30, u...@netbeisser.de a écrit : >>>>> Hi all, >>>>> >>>>> debug3: Incorrect RSA1 identifier >>>>> debug3: Could not load "/home/jeetu/.ssh/id_rsa" as a RSA1 public key >>>>> debug2: key_type_from_name: unknown key type '-BEGIN' >>>>> >>>>> >>>>> On Tue, Oct 18, 2011 at 03:22:08PM +0500, jeetu.gol...@gmail.com wrote: >>>>>> Hi Aris, >>>>>> >>>>>> I've attached a log of the libssh server >>>>>> (log-1-ebpsshd-singlesession-18102011.txt) and the OpenSSH client >>>>>> (log-ssh-1-18102011.txt). >>>>> >>>>> Greetings >>>>> -- >>>>> Stefan Kuttler ==*== nc.netbeisser.de >>>>> >>>> >>>>
Re: Server woes - Bad packet length, corrupted MAC on input
Hi Aris, Just wanted to check in if you've had a chance to try out the libssh server code I've sent and reproduce the errors I've been seeing? Thanks so much again for looking into this. Bye for now On Sat, Oct 22, 2011 at 2:20 PM, jeetu.gol...@gmail.com wrote: > Hi Aris, > > I'm attaching my proof of concept server code > as.ebpsshd-singlesession.c has compile instructions at the > beginning of the code. You will also need to generate a key.h file > that holds the public key of the user who will be connecting to this > server - this is tempoarary since as of now I'm not reading this info > from an authorized_keys or something similar. > > Just create a key.h file in the same directory and put something like : > > #define MY_PUB_KEY "[YOUR PUBLIC KEY WITHIN THESE QUOTES]" > > Also as of now ebpsshd-singlesession listens in on port 2000. So ssh > should connect to that port. > > I also have a libssh-project-wrapper script that allows me to try this > out without needing to install the libssh i've built. It basically has > the content: > > #!/bin/sh > > export > LD_LIBRARY_PATH=/home/jeetu/utils/libssh/libssh-project/build/src:/home/jeetu/utils/libssh/libssh-project/build/src/threads > ./$1 > > I have been testing this code with simple examples like xeyes and > xcalc. For some reason xcalc shows the problem much sooner than with > xeyes, maybe because of the volume of data being transmitted to and > fro? > > This is proof of concept code with a lot of fiddling with buffer sizes > as I have been trying to study if any of that makes an impact however > please point out any way you think this can be improved on :) > > I'm sorry to drop this in your lap especially if it turns out it was > some server side code issue, however I completely appreciate your help > on this. I would like to squash this bug regardless of where it lies > i.e. in my code or libssh, unfortunately my understanding of libssh > and the ssh protocol is a little limited. However I do not want to put > all of this load completely in your lap and if you share your thoughts > and there's something you would like me to look into then please let > me know. > > Thanks, > Jeetu > ebrain.in | Beehive Computing > Discover and run software from any device around you - an open source > (GPL) project. > > > On Fri, Oct 21, 2011 at 11:22 PM, jeetu.gol...@gmail.com > wrote: >> Hi Aris, >> >>> I think I'll need a proof-of-concept code to debug this. Would you mind >>> sharing your code, or it's not possible (too much integration with >>> existing code). >> >> No problem at all :) The code is an independent unit as of now since I >> wanted to make it work before I integrate it within my open source >> project (eBrainPool) >> >> I'll mail this out to you tomm (not on the machine with the code right now >> :) ) >> >> Thanks so much for looking into this.truly appreciate it :) >> >> Bye for now >> >> >> On Fri, Oct 21, 2011 at 7:26 PM, Aris Adamantiadis wrote: >>> Hi Jeetu, >>> >>> By seeing your logs, I understand this: >>> Both side have a hmac error. The openssh client sees it first, sends a >>> disconnect (that works), then there's the error in the libssh log. >>> >>> I think I'll need a proof-of-concept code to debug this. Would you mind >>> sharing your code, or it's not possible (too much integration with >>> existing code). >>> >>> If so, do you think I can reproduce the problem by "fixing" samplesshd >>> to make new X11 channels connection connect to the local X11 unix socket ? >>> >>> Thanks. >>> >>> Aris >>> >>> >>> Le 18/10/11 20:34, jeetu.gol...@gmail.com a écrit : >>>>> This is not a problem and shouldn't cause invalid MAC errors. I'm on >>>>> travel so I'll look at the log when i'm back. >>>> >>>> Thanks so much Aris :) >>>> >>>> On Tue, Oct 18, 2011 at 5:52 PM, Aris Adamantiadis >>>> wrote: >>>>> Hi, >>>>> >>>>> This is not a problem and shouldn't cause invalid MAC errors. I'm on >>>>> travel so I'll look at the log when i'm back. >>>>> >>>>> Aris >>>>> >>>>> Le 18/10/11 12:30, u...@netbeisser.de a écrit : >>>>>> Hi all, >>>>>> >>>>>> debug3: Incorrect RSA1 identifier >>>>>> debug3: Could not load "/home/jeetu/.ssh/id_rsa" as a RSA1 public key >>>>>> debug2: key_type_from_name: unknown key type '-BEGIN' >>>>>> >>>>>> >>>>>> On Tue, Oct 18, 2011 at 03:22:08PM +0500, jeetu.gol...@gmail.com wrote: >>>>>>> Hi Aris, >>>>>>> >>>>>>> I've attached a log of the libssh server >>>>>>> (log-1-ebpsshd-singlesession-18102011.txt) and the OpenSSH client >>>>>>> (log-ssh-1-18102011.txt). >>>>>> >>>>>> Greetings >>>>>> -- >>>>>> Stefan Kuttler ==*== nc.netbeisser.de >>>>>> >>>>> >>>>> >>>> >>> >>> >> >
Re: Server woes - Bad packet length, corrupted MAC on input
Hi Aris, No probs and I completely understand and appreciate your interest in looking into thisplease let me know how I can help further :) Bye for now On Wed, Nov 9, 2011 at 3:32 PM, Aris Adamantiadis wrote: > Hi Jeetu, > > I apologize, still had no time to check it. I'm pretty busy and all my > free time is swallowed by another project. I hope I can free myself an > hour or two next week to debug this. > > kr, > > Aris > > Le 3/11/11 19:13, jeetu.gol...@gmail.com a écrit : >> Hi Aris, >> >> Just wanted to check in if you've had a chance to try out the libssh >> server code I've sent and reproduce the errors I've been seeing? >> >> Thanks so much again for looking into this. >> >> Bye for now >> >> On Sat, Oct 22, 2011 at 2:20 PM, jeetu.gol...@gmail.com >> wrote: >>> Hi Aris, >>> >>> I'm attaching my proof of concept server code >>> as.ebpsshd-singlesession.c has compile instructions at the >>> beginning of the code. You will also need to generate a key.h file >>> that holds the public key of the user who will be connecting to this >>> server - this is tempoarary since as of now I'm not reading this info >>> from an authorized_keys or something similar. >>> >>> Just create a key.h file in the same directory and put something like : >>> >>> #define MY_PUB_KEY "[YOUR PUBLIC KEY WITHIN THESE QUOTES]" >>> >>> Also as of now ebpsshd-singlesession listens in on port 2000. So ssh >>> should connect to that port. >>> >>> I also have a libssh-project-wrapper script that allows me to try this >>> out without needing to install the libssh i've built. It basically has >>> the content: >>> >>> #!/bin/sh >>> >>> export >>> LD_LIBRARY_PATH=/home/jeetu/utils/libssh/libssh-project/build/src:/home/jeetu/utils/libssh/libssh-project/build/src/threads >>> ./$1 >>> >>> I have been testing this code with simple examples like xeyes and >>> xcalc. For some reason xcalc shows the problem much sooner than with >>> xeyes, maybe because of the volume of data being transmitted to and >>> fro? >>> >>> This is proof of concept code with a lot of fiddling with buffer sizes >>> as I have been trying to study if any of that makes an impact however >>> please point out any way you think this can be improved on :) >>> >>> I'm sorry to drop this in your lap especially if it turns out it was >>> some server side code issue, however I completely appreciate your help >>> on this. I would like to squash this bug regardless of where it lies >>> i.e. in my code or libssh, unfortunately my understanding of libssh >>> and the ssh protocol is a little limited. However I do not want to put >>> all of this load completely in your lap and if you share your thoughts >>> and there's something you would like me to look into then please let >>> me know. >>> >>> Thanks, >>> Jeetu >>> ebrain.in | Beehive Computing >>> Discover and run software from any device around you - an open source >>> (GPL) project. >>> >>> >>> On Fri, Oct 21, 2011 at 11:22 PM, jeetu.gol...@gmail.com >>> wrote: >>>> Hi Aris, >>>> >>>>> I think I'll need a proof-of-concept code to debug this. Would you mind >>>>> sharing your code, or it's not possible (too much integration with >>>>> existing code). >>>> >>>> No problem at all :) The code is an independent unit as of now since I >>>> wanted to make it work before I integrate it within my open source >>>> project (eBrainPool) >>>> >>>> I'll mail this out to you tomm (not on the machine with the code right now >>>> :) ) >>>> >>>> Thanks so much for looking into this.truly appreciate it :) >>>> >>>> Bye for now >>>> >>>> >>>> On Fri, Oct 21, 2011 at 7:26 PM, Aris Adamantiadis >>>> wrote: >>>>> Hi Jeetu, >>>>> >>>>> By seeing your logs, I understand this: >>>>> Both side have a hmac error. The openssh client sees it first, sends a >>>>> disconnect (that works), then there's the error in the libssh log. >>>>> >>>>> I think I'll need a proof-of-concept code to debug this. Would you mind >>>>> sharing your code, or
Re: Server woes - Bad packet length, corrupted MAC on input
Hi Aris, > > took me a lot of time and head scratching, but I narrowed it down to a > threading problem. Two of your threads are running ssh loops at the same I can completely appreciate the effort you must have gone through to debug this :)...threading issues can be pesky and since I didn't understand the internals of libssh it was proving quite difficult for me to trace this out.thank you so much Aris :) > I hacked your example so the server_thread() functions leaves early. It > doesn't remove the race but reduces its window. now it works for me, and I'm > able to run an xterm with it. > I strongly recommend that you refactor your code in a singlethread design, > and that you move the x11 callbacks back in the server loop. I just did a cursory test of your code and it definitely runs much better from what I could see :)I will take your advice to heed and try to refactor the code. > > Let's discuss what libssh can do better to help you write better code. > I'm a little concerned, I would ultimately need to handle multiple sessions.the code you saw dealt with a single sessiondo you think this would also trigger similar issues?what precautions do you think I need to keep in mind while I attempt this? Thanks so much Aris, I'm sooo glad to finally have the answer to my question and know that this was a problem in my codenow I can dedicate my energies in this direction :) Bye for now On Mon, Nov 21, 2011 at 3:11 AM, Aris Adamantiadis wrote: > Hi Jeetu, > > took me a lot of time and head scratching, but I narrowed it down to a > threading problem. Two of your threads are running ssh loops at the same > time, and this cause races. The probability that the race causes problem can > be high, because there's a trigger (data on socket) and both threads run > almost the same code at the same time. > > Thread 1: message = ssh_message_get(session); > in server_thread() > Thread 2: ssh_event_dopoll(event, 1000); > in wait_for_something() > > I hacked your example so the server_thread() functions leaves early. It > doesn't remove the race but reduces its window. now it works for me, and I'm > able to run an xterm with it. > I strongly recommend that you refactor your code in a singlethread design, > and that you move the x11 callbacks back in the server loop. > > Let's discuss what libssh can do better to help you write better code. > > Kr, > > Aris > Le 09/11/11 12:38, jeetu.gol...@gmail.com a écrit : >> >> Hi Aris, >> >> No probs and I completely understand and appreciate your interest in >> looking into thisplease let me know how I can help further :) >> >> Bye for now >> >> On Wed, Nov 9, 2011 at 3:32 PM, Aris Adamantiadis >> wrote: >>> >>> Hi Jeetu, >>> >>> I apologize, still had no time to check it. I'm pretty busy and all my >>> free time is swallowed by another project. I hope I can free myself an >>> hour or two next week to debug this. >>> >>> kr, >>> >>> Aris >>> >>> Le 3/11/11 19:13, jeetu.gol...@gmail.com a écrit : >>>> >>>> Hi Aris, >>>> >>>> Just wanted to check in if you've had a chance to try out the libssh >>>> server code I've sent and reproduce the errors I've been seeing? >>>> >>>> Thanks so much again for looking into this. >>>> >>>> Bye for now >>>> >>>> On Sat, Oct 22, 2011 at 2:20 PM, jeetu.gol...@gmail.com >>>> wrote: >>>>> >>>>> Hi Aris, >>>>> >>>>> I'm attaching my proof of concept server code >>>>> as.ebpsshd-singlesession.c has compile instructions at the >>>>> beginning of the code. You will also need to generate a key.h file >>>>> that holds the public key of the user who will be connecting to this >>>>> server - this is tempoarary since as of now I'm not reading this info >>>>> from an authorized_keys or something similar. >>>>> >>>>> Just create a key.h file in the same directory and put something like : >>>>> >>>>> #define MY_PUB_KEY "[YOUR PUBLIC KEY WITHIN THESE QUOTES]" >>>>> >>>>> Also as of now ebpsshd-singlesession listens in on port 2000. So ssh >>>>> should connect to that port. >>>>> >>>>> I also have a libssh-project-wrapper script that allows me to try this >>>>> out without needing to install the libssh i've buil
multithreading for a single session
Hi Aris, I've been continuing work with my libssh server based on suggestions you had made with regards multithreading when we were debugging issues where I was seeing bad packet length, HMAC errors et al. I refactored my code as you had suggested (below) such that there would be only one thread per session, although there could be multiple connects i.e. sessions. This worked fantastic for me and I was able to solve the packet corruption issues caused due to a race condition with multiple ssh loops running. I could therefore have different ssh clients connect to the same instance of the server and X forward simple x clients like xcalc, xclock, xeyes, xgc. Unfortunately as soon as I tried to forward more complex applications such as libreoffice, chromium etc things weren't working. Further analysis and a look at the openssh code showed that these applications spawn multiple connects to the same $DISPLAY. Therefore as I understand it (could be wrong) the server needs to accept and process different event connections on the same session. I have refactored the code again to account for this but basically this reintroduces the same race condition with multiple event handling we had seen earlier and while programs like libreoffice, chromium etc more further along they eventually crash due to bad packet length, mac errors,etc. I tried to protect the event handling function ssh_event_dopoll with a mutex hoping this will resolve the issue, however it didn't make any difference. I'm at my wits end here and could appreciate advice here. One obvious way is for me to somehow refactor my code in a way that eludes me at the moment to get around this issue. The other could be if libssh itself would handle multithreaded event handling for the same session differently or if I am somehow using it in a wrong way. I have created a git repo of my code so anyone can study it. I have not yet put a GPL license header to the code (just realized that ;) ) however I don't care and in fact would be honoured if people would find some use for this code. The code will eventually be part of the eBrainPool (ebrain.in) project which I am working on which itself is GPLv3 - so feel free to use it in any way you want. For now I could really use some ideas on how I could either refactor my code to avoid the above issues or somehow if libssh could be modified to handle multithreading for the same session differently. Thanks, Bye for now Jeetu ebrain.in | Beehive Computing Share your software and computing resources - discover and run software from any device around you. On Mon, Nov 21, 2011 at 5:42 PM, jeetu.gol...@gmail.com < jeetu.gol...@gmail.com> wrote: > Hi Aris, > > > > > took me a lot of time and head scratching, but I narrowed it down to a > > threading problem. Two of your threads are running ssh loops at the same > > I can completely appreciate the effort you must have gone through to > debug this :)...threading issues can be pesky and since I didn't > understand the internals of libssh it was proving quite difficult for > me to trace this out.thank you so much Aris :) > > > I hacked your example so the server_thread() functions leaves early. It > > doesn't remove the race but reduces its window. now it works for me, and > I'm > > able to run an xterm with it. > > I strongly recommend that you refactor your code in a singlethread > design, > > and that you move the x11 callbacks back in the server loop. > > I just did a cursory test of your code and it definitely runs much > better from what I could see :)I will take your advice to heed and > try to refactor the code. > > > > > Let's discuss what libssh can do better to help you write better code. > > > > I'm a little concerned, I would ultimately need to handle multiple > sessions.the code you saw dealt with a single sessiondo you > think this would also trigger similar issues?what precautions do > you think I need to keep in mind while I attempt this? > > Thanks so much Aris, I'm sooo glad to finally have the answer to > my question and know that this was a problem in my codenow I can > dedicate my energies in this direction :) > > Bye for now > > > > On Mon, Nov 21, 2011 at 3:11 AM, Aris Adamantiadis > wrote: > > Hi Jeetu, > > > > took me a lot of time and head scratching, but I narrowed it down to a > > threading problem. Two of your threads are running ssh loops at the same > > time, and this cause races. The probability that the race causes problem > can > > be high, because there's a trigger (data on socket) and both threads run > > almost the same code at the same time. > > > > Thread 1: message = ssh_message_get(session); > > in server_threa
Re: multithreading for a single session
oops forgot to mention the git link where this code can be seen ;)git://ebrain.in:/libssh-server.git :) sorry On Wed, Feb 15, 2012 at 1:59 PM, jeetu.gol...@gmail.com < jeetu.gol...@gmail.com> wrote: > Hi Aris, > > I've been continuing work with my libssh server based on suggestions you > had made with regards multithreading when we were debugging issues where I > was seeing bad packet length, HMAC errors et al. > > I refactored my code as you had suggested (below) such that there would be > only one thread per session, although there could be multiple connects i.e. > sessions. This worked fantastic for me and I was able to solve the packet > corruption issues caused due to a race condition with multiple ssh loops > running. I could therefore have different ssh clients connect to the same > instance of the server and X forward simple x clients like xcalc, xclock, > xeyes, xgc. > > Unfortunately as soon as I tried to forward more complex applications such > as libreoffice, chromium etc things weren't working. Further analysis and a > look at the openssh code showed that these applications spawn multiple > connects to the same $DISPLAY. Therefore as I understand it (could be > wrong) the server needs to accept and process different event connections > on the same session. > > I have refactored the code again to account for this but basically this > reintroduces the same race condition with multiple event handling we had > seen earlier and while programs like libreoffice, chromium etc more further > along they eventually crash due to bad packet length, mac errors,etc. > > I tried to protect the event handling function ssh_event_dopoll with a > mutex hoping this will resolve the issue, however it didn't make any > difference. > > I'm at my wits end here and could appreciate advice here. One obvious way > is for me to somehow refactor my code in a way that eludes me at the moment > to get around this issue. The other could be if libssh itself would handle > multithreaded event handling for the same session differently or if I am > somehow using it in a wrong way. > > I have created a git repo of my code so anyone can study it. I have not > yet put a GPL license header to the code (just realized that ;) ) however I > don't care and in fact would be honoured if people would find some use for > this code. The code will eventually be part of the eBrainPool (ebrain.in) > project which I am working on which itself is GPLv3 - so feel free to use > it in any way you want. > > For now I could really use some ideas on how I could either refactor my > code to avoid the above issues or somehow if libssh could be modified to > handle multithreading for the same session differently. > > Thanks, > > Bye for now > Jeetu > ebrain.in | Beehive Computing > Share your software and computing resources - discover and run software > from any device around you. > > > > On Mon, Nov 21, 2011 at 5:42 PM, jeetu.gol...@gmail.com < > jeetu.gol...@gmail.com> wrote: > >> Hi Aris, >> >> > >> > took me a lot of time and head scratching, but I narrowed it down to a >> > threading problem. Two of your threads are running ssh loops at the same >> >> I can completely appreciate the effort you must have gone through to >> debug this :)...threading issues can be pesky and since I didn't >> understand the internals of libssh it was proving quite difficult for >> me to trace this out.thank you so much Aris :) >> >> > I hacked your example so the server_thread() functions leaves early. It >> > doesn't remove the race but reduces its window. now it works for me, >> and I'm >> > able to run an xterm with it. >> > I strongly recommend that you refactor your code in a singlethread >> design, >> > and that you move the x11 callbacks back in the server loop. >> >> I just did a cursory test of your code and it definitely runs much >> better from what I could see :)I will take your advice to heed and >> try to refactor the code. >> >> > >> > Let's discuss what libssh can do better to help you write better code. >> > >> >> I'm a little concerned, I would ultimately need to handle multiple >> sessions.the code you saw dealt with a single sessiondo you >> think this would also trigger similar issues?what precautions do >> you think I need to keep in mind while I attempt this? >> >> Thanks so much Aris, I'm sooo glad to finally have the answer to >> my question and know that this was a problem in my codenow I can >> dedicate my energies in
Re: multithreading for a single session
Hi guys, Just wanted to know if anyone has had a chance to look into the possibility of multithreading over a single session which I had discussed in any earlier mail here (pasted below). For now for my open source eBrainPool (ebrain.in) project I have gone ahead with piped openssh server and daemon however this is not ideal for variety of reasons. I would love to use libssh however the issues I highlighted earlier prevent me from doing that. Please let me know how I can help with this :)thanks again for all the help everyone here has provided me with in the past :) Regards, Jeetu ebrain.in | Beehive Computing Share your software and computing resources - discover and run software from any device around you. On Wed, Feb 15, 2012 at 2:09 PM, jeetu.gol...@gmail.com wrote: > oops forgot to mention the git link where this code can be seen > ;)git://ebrain.in:/libssh-server.git :) > > sorry > > > On Wed, Feb 15, 2012 at 1:59 PM, jeetu.gol...@gmail.com > wrote: >> >> Hi Aris, >> >> I've been continuing work with my libssh server based on suggestions you >> had made with regards multithreading when we were debugging issues where I >> was seeing bad packet length, HMAC errors et al. >> >> I refactored my code as you had suggested (below) such that there would be >> only one thread per session, although there could be multiple connects i.e. >> sessions. This worked fantastic for me and I was able to solve the packet >> corruption issues caused due to a race condition with multiple ssh loops >> running. I could therefore have different ssh clients connect to the same >> instance of the server and X forward simple x clients like xcalc, xclock, >> xeyes, xgc. >> >> Unfortunately as soon as I tried to forward more complex applications such >> as libreoffice, chromium etc things weren't working. Further analysis and a >> look at the openssh code showed that these applications spawn multiple >> connects to the same $DISPLAY. Therefore as I understand it (could be wrong) >> the server needs to accept and process different event connections on the >> same session. >> >> I have refactored the code again to account for this but basically this >> reintroduces the same race condition with multiple event handling we had >> seen earlier and while programs like libreoffice, chromium etc more further >> along they eventually crash due to bad packet length, mac errors,etc. >> >> I tried to protect the event handling function ssh_event_dopoll with a >> mutex hoping this will resolve the issue, however it didn't make any >> difference. >> >> I'm at my wits end here and could appreciate advice here. One obvious way >> is for me to somehow refactor my code in a way that eludes me at the moment >> to get around this issue. The other could be if libssh itself would handle >> multithreaded event handling for the same session differently or if I am >> somehow using it in a wrong way. >> >> I have created a git repo of my code so anyone can study it. I have not >> yet put a GPL license header to the code (just realized that ;) ) however I >> don't care and in fact would be honoured if people would find some use for >> this code. The code will eventually be part of the eBrainPool (ebrain.in) >> project which I am working on which itself is GPLv3 - so feel free to use it >> in any way you want. >> >> For now I could really use some ideas on how I could either refactor my >> code to avoid the above issues or somehow if libssh could be modified to >> handle multithreading for the same session differently. >> >> Thanks, >> >> Bye for now >> Jeetu >> ebrain.in | Beehive Computing >> Share your software and computing resources - discover and run software >> from any device around you. >> >> >> >> On Mon, Nov 21, 2011 at 5:42 PM, jeetu.gol...@gmail.com >> wrote: >>> >>> Hi Aris, >>> >>> > >>> > took me a lot of time and head scratching, but I narrowed it down to a >>> > threading problem. Two of your threads are running ssh loops at the >>> > same >>> >>> I can completely appreciate the effort you must have gone through to >>> debug this :)...threading issues can be pesky and since I didn't >>> understand the internals of libssh it was proving quite difficult for >>> me to trace this out.thank you so much Aris :) >>> >>> > I hacked your example so the server_thread() functions leaves early. It >>> > doesn't remove the race but reduces its window. now it works
Re: multithreading for a single session
Hi guys, Thank you so much for taking the time to respond :) truly appreciate it :) >>>>> I seem to recall somebody telling me that the if you are going to use >>>>> threads, then you must use a separate session for each thread. The >>>>> application that used libssh that I wrote and used to maintain had a >>>>> separate session for each thread and it worked well. Eddy, yes my server code worked really well after I followed Aris's suggestions and the changes he made. So long as a single session is working with a single thread you can have multiple such sessions to handle different connections and it all works great. Unfortunately the trouble came to surface when I tried forwarding X clients more complex than xeyes et al. That's when I realized these clients were opening multiple channels over the same session. >>>> My favored solution these days is to use a boost io_service to peek at >>>> the session socket, whenever data needs to be processed, an >>>> asynchronous handler is invoked which processes the active channels. Gearoid, I've been thinking along the same lines and if there is a way to refactor my code to be able to handle multiple channels over a single session without the need for multithreading it. Your solution in principle sounds like what would be great, though I'm not sure I understand how I could go about doing this, is it possible for me to see any code displaying this? Would truly appreciate it :) Thanks yet again guys for coming to my rescue (and that of my project :) ). Regards, Jeetu ebrain.in | Beehive Computing Share your software and computing resources - discover and run software from any device around you. On 3/14/12, Eddy Valdes wrote: > Agreed. > > On 03/14/2012 10:47 AM, Gearoid Murphy wrote: >> >> My personal feeling would be to remain single-threaded. Writing >> asynchronous single-threaded code is initially more challenging than >> writing synchronous multi-threaded code but when problems occur, the >> single-threaded context is much easier to diagnose. >> >> On 14/03/12 14:36, Aris Adamantiadis wrote: >>> Do you guys think we should include inside libssh a support for >>> multi-threaded single sessions ? I see a possibility but I also see >>> many things that can go wrong. >>> >>> Aris >>> >>> Le 14/03/12 14:58, Gearoid Murphy a écrit : >>>> It is possible to use a single session in a multi-threaded context as >>>> long as you protect access to the session (and associated channels) >>>> using a session mutex. It's very inefficient however, as every channel >>>> read operation must timeout in order to release the mutex when the >>>> associated channel is inactive so other channels can be processed. This >>>> timeout is the source of the performance penalty, it decimates >>>> bandwidth. I've seen single threaded applications capable of 30-40 mbs >>>> being reduced to 256kps using the multi-threaded approach. >>>> >>>> My favored solution these days is to use a boost io_service to peek at >>>> the session socket, whenever data needs to be processed, an >>>> asynchronous handler is invoked which processes the active channels. >>>> >>>> On 14/03/12 13:38, Eddy Valdes wrote: >>>>> Jeetu, >>>>> >>>>> I seem to recall somebody telling me that the if you are going to use >>>>> threads, then you must use a separate session for each thread. The >>>>> application that used libssh that I wrote and used to maintain had a >>>>> separate session for each thread and it worked well. >>>>> >>>>> Eddy >>>>> >>>>> On 03/14/2012 09:31 AM, jeetu.gol...@gmail.com wrote: >>>>>> Hi guys, >>>>>> >>>>>> Just wanted to know if anyone has had a chance to look into the >>>>>> possibility of multithreading over a single session which I had >>>>>> discussed in any earlier mail here (pasted below). >>>>>> >>>>>> For now for my open source eBrainPool (ebrain.in) project I have gone >>>>>> ahead with piped openssh server and daemon however this is not ideal >>>>>> for variety of reasons. I would love to use libssh however the issues >>>>>> I highlighted earlier prevent me from doing that. >>>>>> >>>>>> Please let me know how I can help with this :)thanks again for >>>>>> all >>>>>> the help everyo
Re: multithreading for a single session
also any clue as to how openssh handles this? it would need to deal with similar issues. I'll try to look at the code too though I think in terms of design and if this is a direction that makes sense for libssh I think one of you guys would be a better judge. In any case I'm all right with an asynchronous handler if that works and am looking forward to seeing some code and try to see if it works in the X client scenario. thanks :) On 3/15/12, jeetu.gol...@gmail.com wrote: > Hi guys, > > Thank you so much for taking the time to respond :) truly appreciate it :) > >>>>>> I seem to recall somebody telling me that the if you are going to use >>>>>> threads, then you must use a separate session for each thread. The >>>>>> application that used libssh that I wrote and used to maintain had a >>>>>> separate session for each thread and it worked well. > > Eddy, yes my server code worked really well after I followed Aris's > suggestions and the changes he made. So long as a single session is > working with a single thread you can have multiple such sessions to > handle different connections and it all works great. > > Unfortunately the trouble came to surface when I tried forwarding X > clients more complex than xeyes et al. That's when I realized these > clients were opening multiple channels over the same session. > >>>>> My favored solution these days is to use a boost io_service to peek at >>>>> the session socket, whenever data needs to be processed, an >>>>> asynchronous handler is invoked which processes the active channels. > > Gearoid, I've been thinking along the same lines and if there is a way > to refactor my code to be able to handle multiple channels over a > single session without the need for multithreading it. Your solution > in principle sounds like what would be great, though I'm not sure I > understand how I could go about doing this, is it possible for me to > see any code displaying this? Would truly appreciate it :) > > Thanks yet again guys for coming to my rescue (and that of my project :) ). > > Regards, > Jeetu > ebrain.in | Beehive Computing > Share your software and computing resources - discover and run > software from any device around you. > > > > On 3/14/12, Eddy Valdes wrote: >> Agreed. >> >> On 03/14/2012 10:47 AM, Gearoid Murphy wrote: >>> >>> My personal feeling would be to remain single-threaded. Writing >>> asynchronous single-threaded code is initially more challenging than >>> writing synchronous multi-threaded code but when problems occur, the >>> single-threaded context is much easier to diagnose. >>> >>> On 14/03/12 14:36, Aris Adamantiadis wrote: >>>> Do you guys think we should include inside libssh a support for >>>> multi-threaded single sessions ? I see a possibility but I also see >>>> many things that can go wrong. >>>> >>>> Aris >>>> >>>> Le 14/03/12 14:58, Gearoid Murphy a écrit : >>>>> It is possible to use a single session in a multi-threaded context as >>>>> long as you protect access to the session (and associated channels) >>>>> using a session mutex. It's very inefficient however, as every channel >>>>> read operation must timeout in order to release the mutex when the >>>>> associated channel is inactive so other channels can be processed. >>>>> This >>>>> timeout is the source of the performance penalty, it decimates >>>>> bandwidth. I've seen single threaded applications capable of 30-40 mbs >>>>> being reduced to 256kps using the multi-threaded approach. >>>>> >>>>> My favored solution these days is to use a boost io_service to peek at >>>>> the session socket, whenever data needs to be processed, an >>>>> asynchronous handler is invoked which processes the active channels. >>>>> >>>>> On 14/03/12 13:38, Eddy Valdes wrote: >>>>>> Jeetu, >>>>>> >>>>>> I seem to recall somebody telling me that the if you are going to use >>>>>> threads, then you must use a separate session for each thread. The >>>>>> application that used libssh that I wrote and used to maintain had a >>>>>> separate session for each thread and it worked well. >>>>>> >>>>>> Eddy >>>>>> >>>>>> On 03/14/2012 09:31 AM, jeetu.gol...@gmail.com wrote: >>>>>>&g
Re: Bad packet length
Hi Aviv, I think Aris and the others here are better equipped to help you, however I've faced similar issues, as you may have read on the thread. While I'm not clear if you've been working on your own server or client wherein you are seeing this problem, however from what was discussed (as I understood it), multithreading over a single session i.e. using the same session in multiple threads causes race conditions which show this behaviour. The solution seems to be to restrict all processing for a single session within the same thread, you can have multiple sessions each within their own thread however multiple threads working on the same session creates problems. I've verified in my own server that so long as you stick to a single session single thread policy, all is well. Unfortunately I've been looking at providing X forwarding on my server and this is a little tricky to have without having the same session worked on by multiple threads. Mechanisms have been suggested to do this by the kind folk here however honestly I haven't gotten around to trying them yet. Hope the above helps, as said maybe the others here can offer a better solution, If you'd like you can also go through the server code I've been working on and my attempts to have all processing for a single session in one thread. The code can be found using - git clone git://ebrain.in/libssh-server.git Bye for now Jeetu ebrain.in | Beehive Computing Discover and use software from devices around you. An open source (GPLv3) project. On Thu, Jun 14, 2012 at 11:15 AM, Aviv Zilberman wrote: > Hi, > > > > I read all the mailing in the archive regarding “bad packet length” issue > and still didn’t understand the solution. > > I am able to write successfully one buffer of data into SSH channel using > process X (Solaris x86), the remote side (VxWorks) read it successfully and > send response. > > Process Y (I used fork() after connect so one process is responsible for > writing while the other for reading – both of them use same channel) read > the message successfully and “automatically” (trigger by libssh) send > SSH2_MSG_CHANNEL_WINDOW_ADJUST message. > > From this moment and so on, every message arrived to remote host through the > channel is dropped due to “bad packet length”. > > Any idea ? > > > > Thanks in advance, > > Aviv > > > > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof.
Re: Bad packet length
Hi Aviv, > As I mention in my mail, I am using multi processes rather multi threads . > The session is being "duplicate" as part of the "fork()" mechanism while one > process only reading from it while other only writing to it. > Can it still be the same root cause ? I think one of the core libssh developers maybe better equipped to answer that, however I suspect that the issue is probably the same since it involves the same session, in your case across multiple processes. Maybe you could put across a detailed libssh packet log some place and that may shed further light. Bye for now On Thu, Jun 14, 2012 at 1:19 PM, Aviv Zilberman wrote: > Hi Jeetu, > > Thanks for replying. > As I mention in my mail, I am using multi processes rather multi threads . > The session is being "duplicate" as part of the "fork()" mechanism while one > process only reading from it while other only writing to it. > Can it still be the same root cause ? > > Thanks in advance, > Aviv > > > -Original Message- > From: jeetu.gol...@gmail.com [mailto:jeetu.gol...@gmail.com] > Sent: Thursday, June 14, 2012 11:12 AM > To: libssh@libssh.org > Subject: Re: Bad packet length > > Hi Aviv, > > I think Aris and the others here are better equipped to help you, > however I've faced similar issues, as you may have read on the thread. > > While I'm not clear if you've been working on your own server or > client wherein you are seeing this problem, however from what was > discussed (as I understood it), multithreading over a single session > i.e. using the same session in multiple threads causes race conditions > which show this behaviour. The solution seems to be to restrict all > processing for a single session within the same thread, you can have > multiple sessions each within their own thread however multiple > threads working on the same session creates problems. > > I've verified in my own server that so long as you stick to a single > session single thread policy, all is well. Unfortunately I've been > looking at providing X forwarding on my server and this is a little > tricky to have without having the same session worked on by multiple > threads. Mechanisms have been suggested to do this by the kind folk > here however honestly I haven't gotten around to trying them yet. > > Hope the above helps, as said maybe the others here can offer a better > solution, If you'd like you can also go through the server code I've > been working on and my attempts to have all processing for a single > session in one thread. The code can be found using - git clone > git://ebrain.in/libssh-server.git > > Bye for now > Jeetu > ebrain.in | Beehive Computing > Discover and use software from devices around you. An open source > (GPLv3) project. > > > On Thu, Jun 14, 2012 at 11:15 AM, Aviv Zilberman > wrote: >> Hi, >> >> >> >> I read all the mailing in the archive regarding "bad packet length" issue >> and still didn't understand the solution. >> >> I am able to write successfully one buffer of data into SSH channel using >> process X (Solaris x86), the remote side (VxWorks) read it successfully and >> send response. >> >> Process Y (I used fork() after connect so one process is responsible for >> writing while the other for reading - both of them use same channel) read >> the message successfully and "automatically" (trigger by libssh) send >> SSH2_MSG_CHANNEL_WINDOW_ADJUST message. >> >> From this moment and so on, every message arrived to remote host through the >> channel is dropped due to "bad packet length". >> >> Any idea ? >> >> >> >> Thanks in advance, >> >> Aviv >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform us >> by e-mail, phone or fax, and then delete the original and all copies >> thereof. > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us by > e-mail, phone or fax, and then delete the original and all copies thereof. > >
Re: example of a server
Hi Tomasz, I've been working on a libssh server that can do X forwarding - this is my primary interest in terms of server capabilities. I intend to eventually use this code as part of my open source eBrainPool project (ebrain.in). Just noticed your original mail and I'm not sure if my server code is a fit in terms of what you are looking for. However if you would like you could go through the code (currently standalone C code) and hopefully use it as an example :) I'd also be more than happy to polish this up and share the code as an example with the libssh project if it is of interest :) - let me know. For now you can get the code with a git clone git://ebrain.in/libssh-server.git I've worked on making the server multithreaded so it can handle multiple connections. Unfortunately there are still some issues since sophisticated X clients typically open up multiple channels over the same session. Multithreading for a single session isn't supported in libssh at the moment therefore I have to device some other mechanism to handle this. Bye for now Jeetu ebrain.in | Beehive Computing Discover and run software from devices around you. Software and Computing as a shared resource. An open source (GPLv3) project. On Mon, Apr 16, 2012 at 3:35 PM, Tomasz Mikolajczyk wrote: > Hi, > > Recently I started investigation of the libssh capabilities. I > analyzed tutorial and various examples but couldn't find a sufficient > example how to implement a non-blocking SSH server. I would like to > achieve the following: > > 1) listening on a TCP socket on a predefined port > > 2) When there is a new connection on the socket I assume that it is a > new ssh client's connection. Then I would like to pass the socket fd > to the libssh saying "handle this connection as the ssh connection". > Is the following pseudo code correct in order to do that?: > > ssh_bind_struct* b = ssh_bind_new() > ssh_bind_set_blocking(b, 0) > ssh_bind_listen(b) > > TCPSocket tcp; > select(tcp.fd); > ssh_bind_set_fd(tcp.fd); > > ssh_session_struct* ses = ssh_new() > ssh_bind_accept(b, ses) > > 3) In the next step I would like to wait on another select and handle > all the requests, like SSH_REQUEST_AUTH, SSH_REQUEST_CHANNEL_OPEN, > SSH_REQUEST_CHANNEL and so on, but in the same time I would like to > check/receive (in a non-blocking mode by waiting on the same select) a > user-passed data. How to achieve that? The "ssh_message_get" is > blocking so I cannot use it. I also found an example of > reading/writing data using ssh_channel_read/ssh_channel_write > functions, however the examples do not show how to receive user data > (channel data) and in the same time handle messages such as > pty-request. > > /Tomek >
Re: Require example / tutorial for SSH Server with libSSH
Hi Ashish, I had been working on using libssh to write a server that would eventually be used in my own open source project. My requirements for this server were essentially public key authentication - password authentication isn't enabled, X forwarding and being able to handle multiple sessions. The code may act as a sufficient enough example on using libssh to build a ssh server implementing the above functionality. Work remains in the area that while simple X clients work - for e.g. xcalc, xeyes,etc - more complex X clients need more work in the code. Unfortunately I've been sidelined from this by other tasks, will get back to it someday soon for sure. Another thing is that the last I tested this code was with libssh in the master as of 7 months ago - I don't know what has changed since then. You can download the code from git://ebrain.in/libssh-server.git Also to others here, I'm perfectly comfortable and in fact would be honoured if people here feel this code could serve as an example for the rest of the libssh users. To that end I am willing to do what it takes - place a GPL license to it (currently it's code I've been developing mainly for myself so there's no GPL header et al in it - at least I don't think there is :P, you can move this code away from my own git onto libssh server, or we can put it up on github, or I could document / comment it, etc. Please let me know. Thanks, Jeetu On Fri, Sep 28, 2012 at 11:28 AM, Ashish Mangla < ashish.man...@ventyx.abb.com> wrote: > Hello > > ** ** > >I am planning to use libssh library to write one SSH server program, so > that SSH Client in Putty can connect to my SSH server. Do you have an > example for writing SSH server using libSSH? > > ** ** > > Regards > > ** ** > > *Ashish Mangla* > Technical Manager, SCADA Communication > > Email: ashish.man...@ventyx.abb.com > (M) +91 9980 187 994 > > *VENTYX* > an ABB company > www.ventyx.com > > 1st Floor, Block - 1, ABB GISL | Bhoruka Tech Park, Mahadevapara | > Bangalore Karnataka 560048 | India > > --- > > > It is not because things are difficult that we don’t dare > > It is because we don’t dare that things are difficult. > > --- > > > ** ** >
Re: X11 Forwarding
Hi Dustin, I'm not a libssh expert and truthfully it's been sometime since I've worked with (March 2012 or so)it to create a server that had the goal of providing X11 forwarding along with public key authentication. I'm not clear if you're trying to create a libssh server or client. If it is the former then you maybe interested in going through my code that you can get using git from git://ebrain.in/libssh-server.git The server does work for simple X clients such as xcalc, xclock,etc. More complicated X applications need multiple threads per session and this was giving me trouble with the way libssh handled (not sure how things stand at this point) multiple connects over a single session. This should give you some understanding of the process on the server end to implement X11 forwarding as I understood it. If you need a client then I think understanding the server end of things may still help you figure out how to implement the inverse in a client. Again function names and capabilities in libssh may have changed since the time. Hope this helps. Feel free to query me on this. Bye for now Jeetu ebrain.in Discover and run software from any device in the resource pool around you. On Thu, Sep 12, 2013 at 4:28 PM, Dustin Oprea wrote: > Does someone have experience with X11 forwarding? I'm current fixing > another anomaly, but I wanted to get my thoughts straight on this. This is > the theoretical process as it makes sense to me: > > 1) ssh_channel_accept_x11(). Is this done between reads on the client, on > a separate thread,.. or where? > 2) At this point, we should have a X11 channel, returned from the accept > call. > 3) ssh_channel_request_pty() > 4) ssh_channel_change_pty_size() > 5) ssh_channel_request_x11() > 6) ssh_channel_request_shell() > > What now? Loop over communication on the shell channel -as well as- the > X11 channel? > > Are there any unnecessary steps, above (like the pty_size() call)? > > > Thanks. This is just about the only principal function that isn't clearly > covered by the tutorials. > > Dustin > >
