restricted shell

[mouring at etoh.eviladmin.org]

On Sun, 29 Apr 2001, Markus Friedl wrote:

> On Sat, Apr 28, 2001 at 12:44:32PM -0400, Gyepi SAM wrote:
> > On Sat, Apr 28, 2001 at 06:24:48PM +0200, Markus Friedl wrote:
> > > it's easier if the sftp-server does chroot.
> >
> > But then scp would also have to do the same thing if we are allowing both.
> > It would seem easier to be to leave sftp-server and scp as they are and
> > centralize the chroot and other related local security measures in the
> > restricted shell, no?
>
> no :)
>
I would much perfer chroot() done in sftp-server.  I plan on looking at
that after I get a few of the other patches queued up done with. =)

> if sshd chroots, you need to copy the (static?) sftp-server
> to every home-dir. this is no fun on solaris, just
> look at the mess ssh-chrootmgr(1) creates.
>
> > > additionally you have to disallow writing of $HOME,
> > > restrict sftp to subdirs only. otherwise the user
> > > can modify .ssh or .forward...
> >
> > I would leave this as an administrator option since I can imagine scenarios
> > where both of those actions might be desirable.
>
> yes, but they are usually not aware of this.
>

Hmm.. .forward is harder to deal with because it's outside the scope of
SSH.  ftp-only accounts have the same issues.

For everything in .ssh it would be nice if we could provide a 'Class'
based system.  So you can assign users to a class which limits what
ssh functionality is accepted, and the ability to set a default.  Much the
same way that ncftpd/proftpd does.

But how much bloat do we need to include to build enough flexibility to
handle the most cases.

- Ben