On Thu, Nov 21, 2002 at 10:17:11PM -0500, R P Herrold wrote:
> On Thu, 21 Nov 2002, Ed Wilts wrote:
>
> > On Thu, Nov 21, 2002 at 07:02:27PM -0500, Steve Howard wrote:
> > > Can I set an upper level directory, /home/user, for example for each
> > > user? I have been able to do this with ftp, but can I do it with ssh?
> >
> > You mean you want to chroot the user so that they can't transfer files
> > outside of that directory? If so, the answer is no, openssh does not
> > support this. Any user that has ssh access to your system (or sftp via
> > the openssh server) has regular access to every file, including your world
> > readable password file. This limitation is why I claim that ftp is
>
> ehhh? If you don't trust them, keep them off your hosts. If
> you can't keep them off a host you admin, don't keep anything
> on _that_ host or in that network segment you wouldn't share
> freely.
Here's the problem, and I'll let you suggest some solutions that are
actually secure. If you can solve this, you're a better techie than I am.
Allow hundreds of authenticated users scattered throughout the
Internet to transfer files. Restrict uploads to pre-determined
directories and downloads to other pre-determined directories. Allow
automated processes to easily do this. Trivial to do with wu-ftpd and
the ftpaccess file, but I've never found a way to allow an scp to honor
any sort of directory restrictions. If any user has scp/sftp access,
then they can simply use this or remote command execution to grab my
system password file, something they certainly can't get via wu-ftpd.
Did I mention that I don't trust these users, even though they're my
customers. I don't expect them to do anything nasty, but that doesn't
mean I trust them either. No user should *ever* be able to see the data
of any other user unless authorized (typically via group membership).
> Failing that, the restricted shell approaches might help.
If ssh is enabled, I believe that any user can simply do this from
another box:
ssh <remote-system> <command>
and the login shell is bypassed. I do not believe that you can prevent
the command line from being executed, even if the users have a
restricted shell. login is not used for remote command execution.
Suggestions greatly appreciated.
.../Ed
--
Ed Wilts, Mounds View, MN, USA
mailto:[EMAIL PROTECTED]
Member #1, Red Hat Community Ambassador Program
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/redhat-list
