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

["Richard E. Silverman" <res%shore.net@localhost>]

On Mon, 12 Mar 2001, Thor Lancelot Simon wrote:
> On Mon, Mar 12, 2001 at 02:40:35PM +0100, Markus Friedl wrote:
> > On Mon, Mar 12, 2001 at 08:31:48AM -0500, Jeffrey Altman wrote:
> > > 
> > > Why do you need to use FTP over SSH when FTP is "securable" using any
> > > number of methods?  The most common methods are
> > > 
> > >   SSL/TLS
> > > 
> > >   GSSAPI 
> > > 
> > >   Kerberos
> > > 
> > >   SRP

Because while FTP may be "securable" using these methods, the fact is that
it has not actually been secured this way in real life.  Implementations
of these things have existed for a while, and have simply not caught on.
I will not debate why, but is is true.  In the short time that it has
existed, my impression is that SSH has achieved much more widespread use
than any of these techniques.  Hence, an easy-to-use, comprehensive
file-transfer protocol that operates over SSH has a good chance of
succeeding where these various secured FTP's have failed.

FTP has successfully been secured using SSH; cf the SecureFX product from
Van Dyke, and the FTP protocol forwarding in the latest version of SSH2
from ssh.com.  However, it's nasty.  The basic FTP techniques of using
multiple, separate TCP connections for data transfers, and carrying IP
addresses inside the command channel, make it badly suited to today's
Internet filled with restrictive firewalls and NAT.  A much better idea is
to have a protocol which requires nothing but a single, reliable,
full-duplex byte stream as its transport.  To my knowledge, there simply
isn't such a thing available.  rcp is too simple; it doesn't allow for
directory listings or generally fetching information about remote files,
and doesn't lend itself to conducting a file-transfer "session," as
opposed to just pushing or pulling a singly-specified set of files.  I
haven't looked at the protocols used by rsync, sup, etc. to see if they
would have been good alternatives -- but they are not standardized,
either.  If there's an existing IETF-standard file-transfer protocol that
meets these needs, I'd like to hear about it.

I agree that on the face of it, engineering such a thing in the context of
the SSH wg is a little odd; it has no direct connection with SSH at all.
But in a practical sense, it does.  People have two immediate needs when
connecting to remote computers: getting a remote command shell, and
transferring files.  SSH inherently provides the former.  By providing the
latter as well as a standard feature, SSH will be more widely used,
enhancing security in the Internet.  Since there is no existing,
widely-used, sufficiently general file-transfer protocol which is easily
securable via SSH, creating a new one is justified.

> I think the point is that the development of the SSH protocol has
> involved a great deal of reinvention of wheels.  Some people think
> that this is regrettable and wish that the SSH working group paid a
> bit more attention to integration with other IETF protocols rather
> than rampaging ahead inventing new ones.
> 
> ... 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.

Tatu Ylönen wrote SSH1 in 1995, a year before the TLS wg was even formed.
The first version of the SSH-2 protocol was designed by SSH Communications
Security in 1996, and the SSH wg formed in 1997.  RFC 2246 documenting TLS
1.0 did not appear until 1999.  So the claim that the SSH people should
have used TLS instead seems a bit stretched; it did not exist at the time.
SSL in its earlier versions existed, but as I noted before, it had not
(and to this day still has not) achieved much use outside of HTTPS.  Why
would Tatu or others have turned to a technology that, for whatever
reasons, had simply failed to do the job in the field?  Its dependence on
an eagerly-awaited-but-never-quite-there-yet global X.509-based PKI, plus
dependence on the overly complex ASN.1/BER/DER suite, were liabilities
just not worth the trouble.

> We have those things now; there's not much point thinking about what
> we _could_ have done. 

An odd statement, considering that you have just spent a fair amount of
space doing exactly this, and berating people for it.

> I don't really think that the "anonymous" bits of its function are well
> served by its design, worse served, in fact, than by simply using FTP
> secured with TLS, GSSAPI, or other standard methods

These methods, no matter how much they may appeal to our sense of elegance
or our like of reusing of existing technology, have simply not taken hold.
They have been rejected by the users.  SSH, on the other hand, is
spreading and gaining acceptance.  A file-transfer method that works over
SSH is therefore a good bet, and in the absence of a good existing
candidate, we are building a new one for the purpose.

> and it's massive overkill compared to the simple BSD-rcp protocol used
> by the old "scp" application, when that's going to be 99% of what it's
> used for in the real world, ISTM.

In the real world, people want long-lived file-transfer sessions including
the ability to list remote directories, push and pull various files during
that single session, perhaps initiate a long transfer and then continue to
list other directories and transfer other files while that long task
continues.  rcp is just not general enough to meet these needs.

-- 
  Richard Silverman
  slade%shore.net@localhost