I need to connect to an SSH server that is running SSLH - a system where HTTPS and SSH both run on port 443. When a client connects, SSLH waits a few seconds to see if the client is going to be the first to send data. Under normal circumstances in an HTTPS connection, the client sends the first piece of data, and in an SSH connection, the server sends the first piece of data. Basically, the client has 5 seconds to initiate SSL negotiation, and if it doesn't, SSLH decides this must be an SSH connection, and it bumps the connection over to the SSH server.
This works with Putty, but it doesn't work with SecureCRT.
Here's what I see in WireShark using Putty, where Putty allows the server to send data first:
<5 second pause after TCP connection>
Server sends: SSH-2.0-OpenSSH_6.4
Client sends: SSH-2.0-PuTTY-Release-0.55
Here's what I see in WireShark using SecureCRT, where SecureCRT immediately sends data after the TCP session connects:
<No pause after TCP connection>
Client sends: SSH-2.0-SecureCRT_8.5.3 (x64 build 1867)
Is there a way to suppress this? I've checked RFC 4253 (SSH) - it just says both server and client must send Protocol Version information, it doesn't say who sends first. In other words, SSLH isn't up to spec with the RFC. Of course, that doesn't help with the fact that Putty is ugly and SecureCRT is my preferred client. I have no control over the server, so no help there, either. Also, I need to connect to this server, so just choosing not to connect isn't an option.