Re: OpenSSH/scp ->> F-Secure SSH server Problems

[Thor Simon <tls%cs.stevens-tech.edu@localhost>]

On Tue, Mar 13, 2001 at 12:12:46AM +0100, Niels Möller wrote:
> Thor Lancelot Simon <tls%rek.tjls.com@localhost> writes:
> 
> > But then again, I think that reinventing most of what TLS does for
> > the SSHv2 transport layer instead of politely asking the TLS folks
> > for a record-oriented interface was rather silly, too.
> 
> I've implemented both TLS (ok, it was actually SSL version 3 back
> then) and ssh2. I'd say the ssh2 transport is better. It's cleaner,
> more secure, more flexible, and its spec is a lot easier to
> understand. And then a lot of the complexity in ssh is in the
> connection layer, which isn't comparable to TLS in any way.

Nonetheless, we have two IETF-standardized secure transport layers
which serve essentially the same purpose.  I find this regrettable,
particularly from the point of view of a small system which, these
days, may be forced to carry around the code to do both.

> The ssh implementation and the sftp implementation are quite
> independent. They have a common origin and uses a common language and

Yeah, that's my point.  I think it's entirely reasonable to *not*
implement sftp in an ssh implementation, given its large size and
general crustiness.

[...snip...]
> Furthermore, the server part (i.e. the subsystem) is not big, I expect
> the one I started to write to be a self contained program of at most
> 5000-10000 lines of C code. Say about twice as large as GNU ls. 

That's pretty darned big; the entire SSHv1 server implementation we 
shipped to Redback, for example, was just about 5000 lines, and we had 
a working minimal server at an earlier point in our development that
was perhaps 2/3 that big.  The entire world is NOT a Unix machine with
a multi-gigabyte hard drive.

I don't think that GNU ls is a particularly good example of a small
program -- it's three times as long as the /bin/ls in the current NetBSD
sources, for example.

Thor