I run a bunch of threads (max 30) which all create a client and connect to the same server, and run a few commands.
All the clients use the same ConnectionInfo object to connect.
The following exception occurs either on Connect, or RunCommand, but mostly on Connect.
Renci.SshClient.Common.SshException: Message type 52 is not valid.
at Renci.SshClient.Session.WaitHandle(WaitHandle waitHandle)
at Renci.SshClient.PasswordConnectionInfo.OnAuthenticate()
at Renci.SshClient.ConnectionInfo.Authenticate(Session session)
at Renci.SshClient.Session.Connect()
at Renci.SshClient.BaseClient.Connect()
at upresources.LinuxSSH.Process(Object sender, DoWorkEventArgs e)
I have seen this behaviour with the max number of threads set to 3, but that was in debug-mode in VS 2010.
Please tell me if there's additional information I can provide.
Comments: ** Comment from web user: drieseng **
All the clients use the same ConnectionInfo object to connect.
The following exception occurs either on Connect, or RunCommand, but mostly on Connect.
Renci.SshClient.Common.SshException: Message type 52 is not valid.
at Renci.SshClient.Session.WaitHandle(WaitHandle waitHandle)
at Renci.SshClient.PasswordConnectionInfo.OnAuthenticate()
at Renci.SshClient.ConnectionInfo.Authenticate(Session session)
at Renci.SshClient.Session.Connect()
at Renci.SshClient.BaseClient.Connect()
at upresources.LinuxSSH.Process(Object sender, DoWorkEventArgs e)
I have seen this behaviour with the max number of threads set to 3, but that was in debug-mode in VS 2010.
Please tell me if there's additional information I can provide.
Comments: ** Comment from web user: drieseng **
I can reproduce this consistently when using the same ConnectionInfo for multiple connections (on multiple threads).
This is because the authentication methods are not thread-safe. The EventWaitHandle and authentication result are on the AuthenticationMethod, and - when its shared by multiple threads - it can lead to the exception mentioned in this issue.
When the EventWaitHandle of an Authenticate invocation for a given session is actually getting set by the authentication attempt of another session, then SSH_MSG_USERAUTH_SUCCESS (and others) is unregistered while the session itself still has to receive this message. Once it receives the message, the exception above is thrown.