Message type 53 is not valid.

Apr 24, 2011 at 12:26 AM

Hey all,

My code snippet:

Renci.SshClient.SftpClient theClient = new Renci.SshClient.SftpClient(sIpAddress, iPort, sUserName, sPassword);

theClient.Connect();

is giving me issues with:

internal void WaitHandle(WaitHandle waitHandle) is throwing "Message type 53 is not valid." during theClient.Connect(); in OnAuthenticate().

I have tested the connection via putty psftp.exe and it connected just fine. Any ideas? Or am I just missing something really obvious.

~Ed

Coordinator
Apr 25, 2011 at 12:35 PM

Hi Ed,

It looks like you doing everything correctly but for some reason my client cannot handle SSH_MSG_USERAUTH_BANNER message.

What is server version that you trying to connect to? I want to see if you could replicate this problem here.

Also, I assume if you use putty to connect to this server it works, right?

 

Thanks,

Oleg

Apr 25, 2011 at 12:58 PM

Hey,

I am connecting to a GlobalScape EFT Server 6.2.25 that I am not hosting, so I dont have access to a config or server setup.

I can't connect via putty (ssh) since I dont have a ssh account there (when I try to connect via ssh I get a "Server refused to allocate pty" message), but I can connect via putty's psftp.exe (sftp) and browse etc just fine.

Thanks,

~Ed

Coordinator
Apr 25, 2011 at 1:13 PM

 

Hi Ed,

 

I just contaced GlobalScape to request an eval copy of the server so I could see where the problem is and solve it.

Will let you know as soon as I have some update regarding this issue.

 

Thanks,

Oleg

Apr 27, 2011 at 1:42 PM

Awesome, thanks!

May 5, 2011 at 2:55 PM

I'm having the same exact issue with the same brand of server. 

I've traced the problem to within the Connect() and Authenticate() methods.

The "SSH_MSG_USERAUTH_BANNER" message is registered within the "Authenticate()" method (in ConnecitonInfo), but this is called (from the Connect() method) after the "MessageListener()" task has started.

The problem seems to be that this (SSH_MSG_USERAUTH_BANNER) message is received by the MessageListener task before it gets registered from within the Authenticate() method. If I set a break point at the line that throws the exception ("message type 53 is not valid"), which is within the LoadMessage() method in the Session class, and I set a breakpoint within the Authenticate() method, where this message is registered, i hit the exception being thrown first, but when I continue, I make it to the authenticate() method (and registering of the message). I don't know the low-level details of how SFTP works, but it almost seems like the message is being sent before it's expected, or the library is setting up to receive it too late.

I hope this helps!

May 5, 2011 at 2:59 PM

FYI,

As a temporary fix, I got it working by adding the code:

this.RegisterMessage("SSH_MSG_USERAUTH_BANNER");

just before the MessageListener task is created:

this._messageListener = Task.Factory.StartNew(() => { this.MessageListener(); }, TaskCreationOptions.LongRunning);

I'm sure this isn't the right way to do it, but it got it working the way I needed, so until there's an official fix, this should work for me. 

FYI, all I'm using this for is connecting and downloading a file.

May 5, 2011 at 3:10 PM

Thanks for the update. This fix should be fine since the banner message in not a critical piece of the transfer. After some testing I'll post back my results.

Coordinator
May 5, 2011 at 3:18 PM

Hi,

 

Thanks for helping me with this problem.

I was trying to follow the SSH definition or I guess in this case recommendation, which says that key exchange must be negotiated first before sending any USER_AUTH_* messages.

So I guess in this case, server ignores it and sends SSH_MSG_USERAUTH_BANNER message prior establishing secure connection.

I just made the changed and check it in. Please try it and let me know if this solution works.

 

Thanks,

Oleg

May 5, 2011 at 3:56 PM

Your updated code works great for me. Thanks for the incredibly fast response!

May 7, 2011 at 7:08 PM

Just ran the updated code and it worked just fine. Thanks for the update.