[clue-admin] User setup for "member" accounts

[Collins Richey]

> On Sat, 1 Jan 2005 19:43:37 -0700, Collins Richey <crichey at gmail.com> wrote:
> > On Sat, 01 Jan 2005 19:09:22 -0700, David Anselmi <anselmi at anselmi.us> wrote:
> > > Collins Richey wrote:
> > > [...]
> > > > I've looked at sshd_config on the clue server and at ssh_config on my
> > > > machine, and I'm not any smarter than I was. I do know that sftp to my
> > > > own account on the clue server (a login account, but no public keys)
> > > > works. I'm trying to sftp to 'junk' on the clue server (a dummy
> > > > account that I setup as a non-login account.) Also, scp of a file to
> > > > junk at clue.denver.co.us works using the public key setup.
> > >
> > > sftp works for me, just like for your real account and Jed's.  Look at
> > > the shell you have for the junk account--maybe sftp requires a real shell.
> > >
> >
> > It's beginning to look that way. Here are the results of some experiments:
> >
> > 1. junk user with shell /bin/false - authentication ok, but immediate disconnect
> > 2. junk user with shell /sbin/nologin (the RH thing) - 'Received
> > message too long 1416128883'
> > 3. junk user with /bin/rbash -authentication ok, but immediate disconnect
> > 4. junk user with shell /bin/bash - aok, received sftp> prompt
> >

On Sat, 1 Jan 2005 22:09:05 -0500, grant johnson <amadensor at gmail.com> wrote:
> How about SCP?  Does that work with no shell?  If so, that may be the
> answer.  The actual back end protocol for the file transfers is at
> least very similar if not identical.  If it requires a shell, maybe
> that would be bad, if SCP creates the same result.
> 
> What happens if the shell is bash, but the .profile starts with exit
> or logout?  Is there a way around this?  Does this let SFTP work?
> 

Thanks for your input, Grant. A few comments

1. It would be really, really nice (tm) if you would not top post.
Basic list netiquette ...
2. We are considering sftp to allow the users to
maintain/create/remove their own
    directories, but we don't want users to have a usable shell.
3. If the user has a normal or restricted shell, there are lots of
exploit possibilities.
4. After extensive googling, I've found a few answers:
    a. Giving the user a shell /usr/libexec/openssh/sftp-server
prevents many abuses. This
        isn't a reall shell, so attempts to run shell commands will fail.
    b. Alas, sftp isn't quite secure! the user can cd anywhere in the
file structure and get
        all sorts of things that would be of interest to malicious
hackers. File permissions
        will restrict puts, however.
    c. There doesn't seem to be a good way to restrict cd to the
user's home directory
         without using a chroot jail.
    d. One possibility is to use the scponly shell
(http://www.sublimation.org/scponly/) which
         has a builtin procedure for chroot jailing a user.
    e. More thought is needed.

-- 
 Collins