SSHv1 and PuTTY

One of the advantages of writing books is that you must double-check everything you thought you knew about a topic. PuTTY is probably the most widely deployed SSH client in the world. I’ve used it for years. It’s good software. (I also use the OpenSSH client, of course.)

To my surprise, PuTTY accepts both version 1 and 2 of the SSH protocol. It prefers version 2, but will accept 1.

Version 1 of the SSH protocol has irremediable problems. If a client accepts SSHv1, an attacker can intercept a new SSH connection and force it to downgrade to SSHv1. He can inject arbitrary commands into the SSHv1 stream. These problems have been known since 1998. Increases in computing power have made executing these attacks much simpler.

Worst of all, Ettercap can decode SSHv1 in real time. If Wireshark cannot decode SSH now, I suspect it will soon.

In my mind, this puts SSHv1 into the same category as Telnet and unencrypted read-write SNMP; stuff that Just Should Not Be On My Network.

I absolutely understand why PuTTY supports SSHv1 by default. The generous people who spend their free time writing PuTTY aren’t interested in supporting folks who can’t be bothered to read the instructions. I might make the same decision in their place.

And yes, host key verification helps eliminate MITM attacks. But do your users really verify host keys? Really and truly? The PuTTY FAQ lists “How do I turn off the annoying host key verification prompt?” as a question. As a sysadmin, I translate this as “yours users don’t verify host keys, and mine don’t either.”

There’s no reason for anyone who actually reads this blog to routinely permit SSHv1, and the appearance of security is worse than no security. I encourage you to disable SSHv1 by default in your and your users’ clients. Users can override the default on a host-by-host basis, but at least they must make the conscious effort. They’ll probably ask you for help. This will help you find lingering SSHv1 servers. If you have some embedded device that only speaks SSHv1, well, you have a job to do. That job should include replacing that device or yelling at the vendor.

How do you disable SSHv1 in PuTTY? Open PuTTY. On the left side, go to Connection->SSH. Select “2 only.” On the left side, select Session (at the top). Highlight “Default Settings.” Click Save. PuTTY saves its configuration in the registry, so you can export this setting and apply it to your client PCs through whatever method you use.

The most annoying part of this change is that PuTTY’s default settings do not propagate to all of the previously saved sessions. You must update them by hand or recreate them. I suspect that you could use some sort of script to update your saved sessions from your registry, but I can’t find such a thing. (This would be a great add-on tool for some Windows programmer looking for a way to contribute to the community.)

I will continue to highly recommend PuTTY to my Windows-based friends, with a note on how to disable SSHv1. As a lowly user who has no right to complain and who doesn’t have to listen to users whinge, though, I’d like to say to the PuTTY folks: researchers broke SSHv1 thirteen years ago. It’s time to stop accepting it by default.

2 comments to SSHv1 and PuTTY

  • Mojo Jojo

    It’s an issue that the PuTTY folks are somewhat aware of:

    http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/ssh2-default.html

    The bigger issue in my mind is that the latest “official” release of PuTTY, 0.60, is 4+ years old. There’s still active development, but it’s not bundled it up into a formal 0.61+. So, even if you were to get SSH-1 turned off by default, that still probably wouldn’t find its way into a release that a typical Windows user would run any time soon. There’s some other (IIRC minor) security issues in the PuTTY 0.60 that most-everyone still uses.

    I’m not a fan of the thinking of developers who number their product as pre-1.0 when it’s clearly way beyond a 1.0 release — PuTTY, OpenSSL, etc.

    1.0 release.

  • [...] Michael Lucas points out something that isn’t new but still needs reinforcement: avoid SSH1. [...]