cat -v harmful stuff

Sorry Theo, but SSH Sucks

“When ssh is the foundation of your security architecture, you know things aren’t working as they should.”Rob Pike

From: 9fans@cse.psu.edu (rob pike)
Date: Mon, 1 Jan 2001 09:37:12 -0500
Subject: [9fans] Re: The problem with SSH2
Message-ID: <20010101143731.DB61F199E7@mail.cse.psu.edu>

My disagreement with SSH is more specific.  It is a securitymonger's
plaything, so has been stuffed with every authentication and encryption
technology known, yet those that are configured when it is installed is
a random variable.  Therefore both sides must negotiate like crazy to figure
how to talk, and one often finds that there is no shared language. This is
idiocy.  The complexity is silly, but much worse is that there isn't at least
one guaranteed protocol for authentication and encryption that both
ends always have and can use as a fallback.  I would argue that that
would always be sufficient, but I know I'm in the minority there.  I do
argue that it's demonstrably necessary.

Algorithms everywhere, and not a byte to send.

-rob


From: 9fans@cse.psu.edu (Boyd Roberts)
Date: Mon, 1 Jan 2001 18:38:51 +1100
Subject: [9fans] Re: The problem with SSH2
References: <Pine.LNX.3.96.1001231113151.31533H-100000@einstein.ssz.com>
Message-ID: <01ca01c073c5$e3c405c0$8692fea9@coma>

real problem with SSH is that its too big and too complicated.

you can't verify it or test it easily.


From: 9fans@cse.psu.edu (rob pike)
Date: Mon, 1 Jan 2001 10:37:00 -0500
Subject: [9fans] Re: The problem with SSH2
Message-ID: <20010101153702.B19F7199E7@mail.cse.psu.edu>

Yes, precisely. By making the thing too complicated, they defeat
the very purpose of security.  Difficult administration results in
incorrect or inadequate installation.  There are cases when I can't
use ssh, a direct consequence.

-rob


From: rsc@pla...
Subject: Re: [9fans] Re: The problem with SSH2
Date: Fri, 26 Jan 2001 14:56:40 -0500

    it may just be the instances you have seen. i've spend a bit of time
    with the draft documents; there is nothing intrinsic to its protocol
    that necessiates those larded implementations. 

no, but there's also nothing intrinsic to the
task at hand that requires such a larded
ad-hoc protocol.  cpu(1) does everything
and more with just 9P and ssl.  while you
might complain about ssl, the complexity
of the ssh protocol is not in the layer-level
encryption code.  it's everything else.
you also might complain that 9P would be
too slow, but i tried it and found that the
small-packet latency was actually _less_
using 9P than using native ssh on the same
unix boxes for various networks.

we're stuck with ssh, but let's not delude
ourselves into thinking it's a good protocol.

(i'm talking about ssh1; ssh2 looks worse.)

russ