Message type 80 is not valid when connecting to OpenSSH 7.1

[martinprikryl]

See http://stackoverflow.com/q/36892391/850848

[drieseng]

I failed to reproduce this issue using version 4_5_2016 of the Microsoft port of OpenSSH.

Can you specify the exact version that you're using ?
If possible, also provide the sshd_config file.

PS. I also sent this response to the SO post.

[martinprikryl]

I actually didn't try to reproduce it. Please contact the original reporter @antmeehan.

[dave-q]

Hi, I've come across a similar issue, however our code appears to be taking a slightly different path to what has been described in the above comments and I'm wondering if this fix will have covered this.

We are currently using Renci.SshNet.dll, v2014.4.6.0

Here is where we begin

using (var sftp = new Renci.SshNet.SftpClient(HostAddress, UserName, Password))
                {
                    sftp.Connect();
                    ...

within that connect we get our SshException saying Message type 80 is not valid.

Here are the exception details including the stack trace

Exception: SshException
Message: Message type 80 is not valid.
Method: Void WaitOnHandle(System.Threading.WaitHandle, System.TimeSpan)
Type: Renci.SshNet.Session
Source: Renci.SshNet

StackTrace:
   at Renci.SshNet.Session.WaitOnHandle(WaitHandle waitHandle, TimeSpan timeout)
   at Renci.SshNet.Channels.ChannelSession.Open()
   at Renci.SshNet.SubsystemSession.Connect()

This seems be different to what has been discussed (I think), in the stackoverflow link, Session.Connect() was being mentioned but we appear to be going via SubSystemSession.Connect() and I was wondering if the fix would cover this or if is still going to occur. The issue is very sporadic and so far impossible for me to reproduce, so unfortunately I cant just try it out and see. Any info would be greatly appreciated.

PS. I didn't create it as a new issue, as I wasn't sure if it was a new issue, if you would like me to I can

Thanks

[martinprikryl]

You code calls SftpClient.Connect, the same as the code in the Stack Overflow post. I do not understand, where you see the difference.

[dave-q]

Apologies that wasn't clear. The article discusses the Session.Connect() method being the source of the exception and this is where the fix was made. However following through using that stack trace it doesn't appear to going through that code and the exception is thrown during the WaitOnHandle

[martinprikryl]

Of course, it goes through that code! If you read the topic carefully, you will see that the solution changed RegisterMessage call. The "register" imply that the call affects further processing of the message, no matter when and where the message is is received.