sftp

[sen_ml at eccosys.com]

From: Pete Chown <Pete.Chown at skygate.co.uk>
Subject: Re: sftp
Date: Tue, 25 Jul 2000 15:00:03 +0100
Message-ID: <20000725150003.J13003 at hyena.skygate.co.uk>

> Ben Lindstrom wrote:
> 
> > This may be a silly idea, but if we are looking to write an "Open
> > Standard" replacement version of the commerical sftp, and we currently
> > agree that doing ssh w/ standard ftp would be a pain in the arse.  What
> > would stop us from using passive ftp?
> 
> How would passive FTP help?  You could set openssh to forward the
> control connection, but the ports for the data connections would be
> chosen at random by the server.
> 
> > It does not spawn off a data channel.
> 
> Someone will correct me if I am wrong, but I thought it did. 

that's my understanding too.

> HTTP might be a better bet, but then we would have to define a format
> for directory listings.  HTTP can transfer files fine, but directory
> listings are usually just HTML designed for humans to read.

fwiw, there's webdav that can be port-forwarded...though it doesn't
seem to be widely deployed yet.

> (BTW, on a different subject, I've been looking at supporting the
> OpenPGP key blobs described in the secsh drafts.  The client basically
> works but the server still needs a bit of work.  It's looking quite
> interesting though -- for example you can arrange it so that signing
> someone's key is sufficient to enable them to log in.)

so, are you going to write an openpgp packet manipulation library?
that'd be very useful for other purposes as well -- for instance, it
could be used to write a pam module that will allow a
challenge-and-response type of authentication using openpgp keys.

for reference, there's someone who's writing an openpgp implementation
in java -- i mention it because there are design details available at:

  http://cvs.cryptix.org/~edwin/openpgp/design/

and more info at:

  http://www.cryptix.org/products/openpgp/index.html