Let's protect a large and complicated codebase which has a long history of security vulnerabilities with a very small and easily audited utility.

I totally agree with the principle - smaller code base, considerably less potential for security holes - but in practice, how many eyeballs have audited spiped in its one year since release (and how many of those belonged to crypto-experts - I, for one, couldn't possible spot any vulnerabilities)?

You have a very good track record of course, so that should count in favour of spiped, but on the other hand there's also some value in the massive user base of openSSH, when it comes to auditing.

What are you protecting? You can't brute force key-based authentication for SSHd.

I'm talking about security vulnerabilities in OpenSSH.

Is there really a history of security vulnerabilities in OpenSSH? (not openssh as patched by idiotic linux distributions)

There have been problems... http://www.openssh.org/security.html

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.

Yes

Bookmarking this comment as an example of one approach to security... we'll see how it turns out!

You can brute force sshd: while true select a random common login select a random common password loop over many many hosts having sshd try to connect to sshd

Well that's their fault for using passwords, not keys.

It is the default configuration on ubuntu boxes

It's the default on every install I have ever used, as you have to be able to install your key in the first place. That isn't solved by `spiped`.

Worst case scenario, there's an exploit that punches through spiped. Now you can connect to SSH in the usual manner.

As far as I can see, in the absolute worst case scenario, you end up in an equivalent position to not running spiped at all - it adds, it does not subtract. It's like putting a second locked door in front of the front door to your house - if someone bypasses it, it doesn't make the other door less secure.

I agree, but it could give a false sense of security to a novice.

What if they set up `spiped` and password authentication?

Also, once they get to `spiped` they are on your system. If there is a whole to run arbitrary commands from `spiped`, you're stuffed.

> If there is a whole to run arbitrary commands from `spiped`, you're stuffed.

Oh, duh, of course. Forget what I said before. Unless you're running spiped in a separate VM or jail.