[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Connection problem with libssh-0.4.8


Hi,

 

We are developing an ssh client/server application using the libssh-0.4.8
library (the server application is used only for testing of client
application). The application is developed for Red Hat Enterprise linux 5.4,
and when we compile our server and client application we can successfully
establish connection and exchange data between those two applications. 

 

But when we use our client application and connect to some other server (in
this case F-Secure SSH for Windows NT Server) we cannot establish a
connection. When debugging our client application with the gdb debugger we
can see that the libssh dh_handshake() function (used in our client
application) expects an SSH2_MSG_KEXDH_REPLY to a SSH2_MSG_KEXDH_INIT
request, but the F-Secure SHH server returns a SSH2_MSG_NEWKEYS message and
after that our client drops the connection. We are able to login to the
F-Secure SHH server when using the ssh cmd on our Linux system and also an
SSH connection can be made from a Windows system using another SSH client.

 

In the client.c code we see that ssh_connect() calls dh_handshake() which in
turn calls packet_wait() (on line 284):

      rc = packet_wait(session, SSH2_MSG_KEXDH_REPLY, 1);

      if (rc != SSH_OK) {

        goto error;

      }

 

This call fails because while expecting the SSH2_MSG_KEXDH_REPLY packet,
first we get an SSH2_MSG_IGNORE packet which is directly followed by a
SSH2_MSG_NEWKEYS packet. As this is not expected and not ignored, the call
to packet_wait() fails. When testing with a client and server that both make
use of libssh we see that SSH2_MSG_KEXDH_REPLY is send by the server before
the SSH2_MSG_NEWKEYS packet and as a result, the connection succeeds.

 

We fail to understand why the F-Secure SSH server is sending the
SSH2_MSG_NEWKEYS packet instead of the SSH2_MSG_KEXDH_REPLY. Attached to
this mail you will find a Wireshark capture of a failed connection attempt,
the client has IP 10.57.112.145 and the server has IP 10.28.0.11. We would
appreciate it if you could have a look at this dump file and provide your
opinion on this matter. We are not allowed to change the remote system so
we're stuck with the F-Secure SSH server.

 

Thank you very much for your time and effort!

 

Best regards, We are developing an ssh client/server application using the
libssh-0.4.8 library (the server application is used only for testing of
client application). The application is developed for Red Hat Enterprise
linux 5.4, and when we compile our server and client application we can
successfully establish connection and exchange data between those two
applications. 

 

But when we use our client application and connect to some other server (in
this case F-Secure SSH for Windows NT Server) we cannot establish a
connection. When debugging our client application with the gdb debugger we
can see that in the client.c code  ssh_connect() calls dh_handshake() which
in turn calls packet_wait() (this is on line 284):

      rc = packet_wait(session, SSH2_MSG_KEXDH_REPLY, 1);

      if (rc != SSH_OK) {

        goto error;

      }

 

This call fails because while expecting the SSH2_MSG_KEXDH_REPLY packet,
first we get an SSH2_MSG_IGNORE packet which is directly followed by a
SSH2_MSG_NEWKEYS packet. As this is not expected and not ignored, the call
to packet_wait() fails. 

 

When testing with a client and server that both make use of libssh we see
that SSH2_MSG_KEXDH_REPLY is send by the server before the SSH2_MSG_NEWKEYS
packet and as a result, the connection succeeds. Also, we are able to login
to the F-Secure SHH server when using the ssh cmd on our Linux system and
also an SSH connection to this server can be made from a Windows system
using another SSH client.

 

We fail to understand why the F-Secure SSH server is sending the
SSH2_MSG_NEWKEYS packet instead of the SSH2_MSG_KEXDH_REPLY. Are we not
using libssh correctly? Attached to this mail you will find a Wireshark
capture of a failed connection attempt, the client has IP 10.57.112.145 and
the server has IP 10.28.0.11. We would appreciate it if you could have a
look at this dump file and provide your opinion on this matter. We are not
allowed to change the remote system so we're stuck with the F-Secure SSH
server.

 

Thank you very much for your time and effort!

 

 

Kind regards,

Nenad Pascan

 

o n e 2 m a n y

Leeuwenbrug 115

7411 TH Deventer

The Netherlands

 

T: +31 (0)88 00 349 21

E:nenad.pascan@xxxxxxxxxxx

www.one2many.eu

 

This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It contains proprietary material, confidential
information and/or be subject to legal privilege. It should not be copied,
disclosed to, retained or used by, any other party. If you are not an
intended recipient then please promptly delete this e-mail and any
attachment and all copies and inform the sender. Thank you.

 

Attachment: BSC.cap
Description: Binary data


Follow-Ups:
Re: Connection problem with libssh-0.4.8Andreas Schneider <asn@xxxxxxxxxxxxxx>
Archive administrator: postmaster@lists.cynapses.org