SFTP Client and strange response from GlobalSCAPE with DSS
Posted: Thu 18 Mar 2010 21:39
A customer of ours has two SFTP servers, one for testing and one for production.
The two servers are identical apart from the fact that the test server is using RSA encryption and the production server is using DSS.
When connecting to the test server, our software has no problems what-so-ever, but when connecting to the production server we routinely experience "SSH Server not responding errors".
Stepping through the code we see that this is occuring immediately upon connection, not the result of a time out.
Inspecting the response from the server, we have found that the TProtocolNegotiationHandler.OnData is receiving a much larger buffer from the production server than the test server.
For the test server the buffer received contains the server version string:
SSH-2.0-1.36_sshlib GlobalSCAPE
From the production server, but buffer contains a similar version string:
SSH-2.0-1.36 sshlib: GlobalScape
But in the same buffer, being processed by TProtocolNegotiationHandler.OnData there is a further string of data (the buffer size is 258 bytes in total) which appears to contain some form of key algorithm identification or possibly key data itself.
TProtocolNegotiationHandler.OnData normally fails (with a misleading "Server not responding" error) due to the fact that the buffer is not terminated by the char. After modifying this method to locate the within the buffer and extract the server version string from the buffer up to that point, the problem then changes.
With that change in place, sometimes the connection is successful (roughly 1 time in 10, but not predictable), but usually there is instead an error:
"Socket closed. Cannot receive data"
I am at a loss to understand why the SecureBridge SFTP client component has these problems with this server when other SFTP client applications such as Tunnelier work without issue.
We need this issue resolved a.s.a.p.
Many thanks in advance.
There are no problems when connecting to the production server using SFTP client software such as Bitvise Tunnelier.
The two servers are identical apart from the fact that the test server is using RSA encryption and the production server is using DSS.
When connecting to the test server, our software has no problems what-so-ever, but when connecting to the production server we routinely experience "SSH Server not responding errors".
Stepping through the code we see that this is occuring immediately upon connection, not the result of a time out.
Inspecting the response from the server, we have found that the TProtocolNegotiationHandler.OnData is receiving a much larger buffer from the production server than the test server.
For the test server the buffer received contains the server version string:
SSH-2.0-1.36_sshlib GlobalSCAPE
From the production server, but buffer contains a similar version string:
SSH-2.0-1.36 sshlib: GlobalScape
But in the same buffer, being processed by TProtocolNegotiationHandler.OnData there is a further string of data (the buffer size is 258 bytes in total) which appears to contain some form of key algorithm identification or possibly key data itself.
TProtocolNegotiationHandler.OnData normally fails (with a misleading "Server not responding" error) due to the fact that the buffer is not terminated by the char. After modifying this method to locate the within the buffer and extract the server version string from the buffer up to that point, the problem then changes.
With that change in place, sometimes the connection is successful (roughly 1 time in 10, but not predictable), but usually there is instead an error:
"Socket closed. Cannot receive data"
I am at a loss to understand why the SecureBridge SFTP client component has these problems with this server when other SFTP client applications such as Tunnelier work without issue.
We need this issue resolved a.s.a.p.
Many thanks in advance.
There are no problems when connecting to the production server using SFTP client software such as Bitvise Tunnelier.