OpenSSH GSoC Project

[Ben Lindstrom]

On Mar 24, 2009, at 6:13 AM, Salvador Fandino wrote:

> Jim Knoble wrote:
>> On 2009-03-23 16:05, Pavel Labath wrote:

[..]

> - even if there is no RFC for SCP, there is a reference implementation
> (rcp), and the protocol is so simple that it can be inferred just
> inspecting a couple of sessions.

- It is known to break very easily due to scp not being found in the  
user's path correctly (thus the reason "subsystems" came into being)

- It is known to require double-escaping of arguments sometimes due to  
the interaction with shells on both sides.  Which causes new users to  
complain that it is broken.

For us to improve scp and make it a real program instead of a "tar |  
ssh tar"ish hack that it is right now.  It would no longer be  
compatible with the existing scp.  At that point, one may as well  
improve sftp since there is still time to nudge the draft into better  
shape.

[..]

>> That said, i often use either rsync(1) or combinations of ssh(1) and
>> tar(1) to do transfers from a shell command-line.
>
> Something I would find very useful would be some SFTP extension to  
> allow
> implementation of some kind of rsync over SFTP.

<shrug> I have a half-written rsync spec and proof of concept  
somewhere around my home directory.  The problem with creating an  
rsync-like concept over sftp is the work needed to teach the sftp  
protocol how to correctly handle rolling checksums.  No matter how I  
write the specs and how I implemented it the cost always felt too  
high, and in benchmarks against rsync it always lost out.

sftp protocol doesn't lend itself well to it at this time.

[..]

>> Again, look at LFTP for ideas.
>
> as LFTP already seems to do everything we need (and much more) and  
> it is
> freely available, does really makes sense to reimplement its
> functionality inside sftp? why not just recommend it on the docs?

Frankly, I don't want to install another  3rd party program and manage  
it along side OpenSSH.  I'd rather have a reasonable sftp  
implementation so my users don't complain.


> I think that there are other more interesting areas to work on related
> to SFTP, for instance:
>
> - remove the max packet size limitation for read and write operations
> that forces SFTP clients to send/get data in chunks. File data could  
> be
> moved directly between the network (actually from the slave SSH  
> process
> pipes) and the on disk file without going to a memory buffer first.

I suspect that would break the current RFC draft.  Thus would either  
an official way to detecting, or an unofficial hack, your talking to  
an older server.

> - implement an extension to allow rsync over SFTP (ssync :-)
>
> - implement fine grained access control for the SFTP server, limiting
> which SFTP operations are available (for instance, forbidding  
> directory
> reading).

The file permissions should be access control.  Having yet another  
layer on top of it is silly.  The only valid argument ftp has for  
doing such garbage is they support an "anonymous" mode where it isn't  
a real user.

> - implement file locking
>
> - implement an extension to tell the client the encoding used on the
> server file system.
>
> - implement an extensible SFTP server in a high level language as Perl
> or Python.


Ugh.  No thank you.   After dealing with broken scripts at least once  
a month I have no interest in seeing sftp-server become a script.   
Unless you don't use any CPAN modules there is no way to assure that  
your new sftp-server will be compatible with the perl version  
installed on the machine (nor is it installed on every class of  
machine).   <shrug> As for python it isn't installed by default under  
every OS.

OpenSSH project already gets people whining that we have too many  
dependancies.

- Ben