From mboxrd@z Thu Jan  1 00:00:00 1970
From: rsc@plan9.bell-labs.com
Message-Id: <200101261956.OAA30860@smtp4.fas.harvard.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: The problem with SSH2
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Fri, 26 Jan 2001 14:56:40 -0500
Topicbox-Message-UUID: 53215bcc-eac9-11e9-9e20-41e7f4b1d025

	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