I was testing out all my stored SSH profiles and ran across one that just hung at a black screen. No logon prompt at all. It just timed out and died.
I exported the Registry entry for that profile and imported it into another machine. PoTTY 0.60 handles it fine. PuTTY 0.61 handled it fine.
Monday night I decided to compile a new "Debug" build to chase this issue down, and although it compiled fine, it crashed every time I tried to run it. This was a very bizarre linker problem. Basically I had to cast some functions from
(BOOL (WINAPI *)()...)
...in arc4random.h, code I pulled from somewhere back in 2010 when I first hacked this thing together. When the debug version finally ran without crashing—about three hours later—it was no help.
The PoTTY log was no help either, so I did a Wireshark snoop on the line, which I should have done in the first place. And I saw the handshake in clear text, so something definitely wasn't right, since this was supposed to be an obfuscated connection. And I noticed the version was "SSH2.0-PuTTYObfuscated".
I didn't like that one bit.
The bug turned out to be the "2 only" radio button under "Protocol options" in the "Connection\SSH" section of the config. Set to "2", it's fine. It took at least another three hours to find it.
Something has changed in ssh.c and I can't seem to find exactly where it is. Some functions are called in a different order and at least one from 0.60 is simply gone in 0.61. Otherwise as long as you don't select "2 only" everyone's happy.
I have a work-around for a saved profile with "2 only" selected, but nothing prevents the user from switching it back. That won't work in the long run so it remains unresolved right now.
While I was poking around in that part of the code, it occurred to me that I knew nothing about using SSH 1.0 with obfuscation. It didn't work. Was it supposed to work?
I did a reality check with brl's code on both the client and the server ends and found that it doesn't work with SSH 1.0, but it also doesn't throw any "not supported" errors. I changed that. Now you get a "not supported" messagebox before obfuscation bombs out against a 1.0 connection.
The "SSH2.0-PuTTYObfuscated" handshake bothered me a lot, since that makes for an easy IDS signature when you have to connect to an unobfuscated server. Of course, it's no big deal when the connection is obfuscated, but you don't want to tip your hand with an off-the-wall SSH version string like that.
So I changed it to "SSH2.0-Debian4.3[something]", which is the dirty trick. Not having "PuTTY" somewhere in the string would put the finger on someone running Linux instead of Windows (sure, you can run PuTTY on Linux, but few people do).
That appealed to my Dark Side, but it would make SSH purists shit their pants, especially if that particular SSH version ever has problems in the future. I looked at extending this to make a user supplied version string, but there isn't enough real estate on any of the dialog boxes to add it. It just won't fit.
I have yet to hack the SSH1.0 version string, but the "2 only" problem has to be fixed by tomorrow night in order to release 0.61 for the weekend.
I told you not to hold your breath.
UPDATE 08/25/2011The "2 only" bug really sucked ass in a big way. I have made the hack-around permanent. Your "Preferred SSH protocol version" will always be "2" and only "2" (not "2 only") whenever you have obfuscation enabled.
The bug was curiouser than it first appeared. It did not disable obfuscation. What actually happened was the plain text version string was getting copied into the buffer that held the already obfuscated data. Really weird.
This issue relates to the "-2" switch for the command-line utilities, so I'll need to do some testing on that as well. Other than that I feel like we're back on track for a weekend release.
Post a Comment