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

From: Thor Simon <[email-masked]>
Date: Mon, 12 Mar 2001 18:49:01 -0500

On Tue, Mar 13, 2001 at 12:12:46AM +0100, Niels Möller wrote:
> Thor Lancelot Simon <[email-masked]> 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

---

From: Damien Miller <[email-masked]>
Date: Tue, 13 Mar 2001 10:56:57 +1100 (EST)

> implement sftp in an ssh implementation, given its large size and

I don't think that you have demonstrated that sftp is either large or
'crusty'. Could you give examples of the latter?

> a multi-gigabyte hard drive.

The sftp-server that we ship with OpenSSH is 1028 lines, not counting
the infrastructure shared with the rest of the implementation. BTW I
don't think that SSH1 is a valid benchmark for comparison.

-d

-- 
| Damien Miller <[email-masked]> \ ``E-mail attachments are the poor man's
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer

---

From: Thor Simon <[email-masked]>
Date: Mon, 12 Mar 2001 19:07:22 -0500

> 'crusty'. Could you give examples of the latter?

I think I'd have to define it a bit better first. :-)  Later tonight
maybe.

> don't think that SSH1 is a valid benchmark for comparison.

Well, Niels suggested 5000-10000 lines.  That's "big" by my definition,
and I do think that it was reasonable to point out that at that size,
it'd be larger than an entire v1 implementation; that implementation
was already too damned big for an embedded system, as far as I was
concerned.

Anyone got a line count for the sftp client and server in the ssh.com
code?  I'd look myself, but for various reasons I don't read through
that codebase, just the specifications.

You can't get much simpler than "rcp", and it works.  It's a shame
that the traditional BSD "rcmd" semantics don't patch stderr,
which forces you to ship a whole separate "scp" command instead
of just using your system rcp (the wire protocol is the same).

Thor

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 12 Mar 2001 19:31:04 -0500

[working group chair hat off.  totally random commentary time.]

In a past job I worked on a small portable IP stack for embedded
platforms.

For the embedded world, one other attraction in favor of SSL/TLS-based
protocols is that, due to the proliferation of web-based management
schemes, embedded boxes which care about security are pretty likely to
have an SSL/TLS implementation in there already for "secure" web-based
mgmt...

					- Bill

---

From: [email-masked] (Niels M�ller)
Date: 13 Mar 2001 01:38:47 +0100

> was already too damned big for an embedded system, as far as I was

Well, that's because my sftp code by intention is *not* sharing any
infrastructure with anything. I'm copying some code from GNU
fileutils, though, for creating the "longname" strings and caching
info about users and groups.

This is kind-of an experiment. I don't particularly like having to
write yet another sftp server. Markus kindly provided me with (an
early version of) his sftp code for me to look at. But it seemed too
tied in with the rest of openssh for me to use directly. So I'd like
to have a standalone sftp program that isn't particularly tied to
either lsh or openssh. I don't know if the openssh folks are
interested in that, I understand that it is easier to just reuse the
openssh code that they have around.

And it may end up smaller than 10K lines, that was a very crude guess.
The current count is 2000 lines including *everything* except libc, so
perhaps it can be completed well under 3-4K lines.

Regards,
/Niels

---

From: Markus Friedl <[email-masked]>
Date: Tue, 13 Mar 2001 09:29:40 +0100

> That's pretty darned big; the entire SSHv1 server implementation we 

Well, you are talking about SSH protocol v1 without any forwarding.

Remember that the channel layer is the most complex part of the SSH
protocol.  TLS does not include anything like the channel layer and
this is why SSH gets used:  People are forwarding all kind of things
over SSH.  Without the channel layer SSH would be just something
like telnet with encryption.

If you are talking about lines, the sftp-server included in OpenSSH
is just about 1000 lines, and could probably implemented with
less lines if this was an issue.  The sftp protocol is not complex
at all.

> shipped to Redback, for example, was just about 5000 lines, and we had 

Hm, this is rather big for server-only if you consider that the plan9
SSH protcol v1 client+server+keygen+manpage is about 4000 lines.

-m