sftp client

[Mats Andersson]

Hi,

On Fri, 9 Feb 2001, Markus Friedl wrote:
> > On Fri, Feb 09, 2001 at 09:02:06AM -0800, Devon Bleak wrote:  i
> > personally would like to see the requirement of a valid shell dropped.
>
> give them a shell that does chroot and exec of sftp-server

Though I can understand the implementation pros and cons of having a user
shell exec the subsystem in general, and the sftp-server in particular. It
is IMHO bad that the discussion of running the subsystem in a shell or not
have to be dealt with in the first place. If an implementation chooses to
run subsystems from a shell, fine, it should take care of all kinds of
problems that might occur too and/or cope with lusers "breaking" the
protocol running on top of it (it is unfortunate that the drafts says that
subsystems are normally run in a shell, it seems to implicate that
subsystems are in fact just yet another way to do rsh with ssh).

There is three kinds of session channels, "shell", "exec", and
"subsystem". If one would want a shell for this kind of stuff one would
choose "exec" (i.e. the rsh equivalent, e.g. for running scp). As it is
now, there is not much benefit in having the sftp protocol run as a
subsystem. It might aswell run as an "exec" session (the only benefit is
of course that the client doesn't have to know the name of the sftp-server
program but that seems quite minor...). One benefit of having it run as a
subsystem might for example be that the subsystem itself knows something
about what users can and can't do independantly of the shell which happens
to be in effect. This is of course just a subtle config/implementation
issue as to how to handle user configuration, though it seems nice to be
as flexible as possible with the given choices for how to do things (i.e.
in this case how one can utilize the "shell", "exec", "subsystem" sessions
of ssh2).

Cheers,

/Mats