So technically those are all "vulnerabilities in openssh", but most of those are either attacks on the key generation process, X11 forwarding, or privilege escalation on the host machine from a legitimate login - none of which would be protected against by the suggestion in the story.

The first one I see where this defense would actually be helpful is the "September 23, 2003: Portable OpenSSH Multiple PAM vulnerabilities", which only applies against a nonstandard PAM configuration, where enabling PAM at all is something openssh doesn't recommend. The next is "April 21, 2002: Buffer overflow in AFS/Kerberos token passing code" - again, an obscure login protocol that's disabled by default.

The first vulnerability that would affect "normal" users is the "Feb 8, 2001: SSH-1 Daemon CRC32 Compensation Attack Detector Vulnerability", 11 years ago. Even if you want to count the "nonstandard config" vulnerabilities, we're still talking 8 years since any real attack, for possibly the most high-profile encryption software in the world. That's a track record I'd put more faith in than spiped's.

If you want to secure your openssh you'd get a better return on your time (IMO) by disabling any login methods you don't use (or, even better, switching entirely to single-use keys), and rate limiting login attempts from a single IP.

I completely agree, but I thought it only fair to list the vulnerabilities. On the other hand, most of it didn't make sense to me... Though that should worry me more than you and thanks for your explanation. :)

Having said that, the vulnerability you pointed out was in SSH1, right? Isn't that depreciated?

>Having said that, the vulnerability you pointed out was in SSH1, right? Isn't that depreciated?

It is now. I'm not sure it was in 2001.