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

[Collins Richey]

On Tue, 04 Jan 2005 00:20:22 -0700, Ronald Kuetemeier
<ronald at kuetemeier.com> wrote:
> Some comments from your friendly PHB of some sys admin organizations.
> I have followed this thread with fascination and still don't know what
> you really want to archive.

Thanks for your comments. I'm not sure what you mean by "archive".  If
you have followed this rather lengthy thread, what we are proposing is
quite simple, but the methods to accomplish the requirements have not
been finalized:

1. Provide each registered members with a public website
(http://clue.denver.co.us/~userid) which can be maintained by the
member using scp and/or sftp (not a login account) without action by
an admin. It is preferred that members be able to add/remove their own
directories but not be able to see/modify anything else. Disk quotas
will be established.

2. Provide each member with an external email alias to allow automatic
forwarding of mail addressed to userid at clue.denver.co.us. Preferrably,
the user will be able to update his alias when his email address
changes without action by an admin.

3. Use public key authentication for all access to the server.

4. Minimize the security risks to the server.

> Anyhow there should be no experimentation on a production server.  The
> reason is if you make changes to files and get it half way working you
> most likely will not back out changes and keep trying until you got it
> working. Now if you are unlucky you got it working without the first
> changes, which you have not backed out (uuuups).  So you have to wipe
> the system and make only the changes you have to make to be save.
> 

All of this is fine and dandy, but we don't have the luxury of an
alternate testing server. Actual changes to files (other than the
admins' personal id's) is minimal and under control. We have an admin
wiki for recording the (semi)final setup. Nothing that is currently
being tested will be committed as permanent until we have a consensus
about the plan.

> Some comments to ssh.
> There is a patch for sshd to run a chroot environment, if you
> understandingly don't want to patch all the time there is a problem with
> ssh.
> You still can run sshd in a chroot, I've attached a file which creates
> the environment. But you still have to maintain the passwd file in
> <chroot>/etc/, btw I run chroot on /home. You should also run a separate
> sshd for admins on a different port without chroot, firewall this port
> and allow only connections from known host. This has the advantage that
> you can  have two different sshd_config files, one for users and one for
> admins.
> 

Your chroot script looks like a simpler version of several that I have
reviewed recently. I'll evaluate it when time permits.

> If you don't want to jump through the hoops for chroot, and don't care
> if users can run commands over ssh, just add no-pty to the users 
> authorized_keys2 file which prevents bash from running.  .

Interesting to know. However, we probably have no choice about using
chroot. We prefer to allow sftp so that members can modify their own
environment with ease, but only their own environment. sftp is ideal
for this use, but unfortunately it will allow the use to cd to any
visible directory (not what we want). Currently I'm experimenting with
sftp-server as the (extremely limited) shell for user accounts. Except
for the cd problem, it appears to be ideal: users can't run scripts
and attempts to escape to another shell reach a dead end.

The scheme about coping the *.pub
> file to authorized_keys2 won't work since people can have multiple
> machines they are using to cp files.

Apparenly authorized_keys2 is antequated. Our ssh setup only works
with aurhorized_keys. As long as members maintain a copy of their
private keys on each machine/os they use, there is no problem
authenticating from multiple machines. I currently have two separate
linux distros setup that way, and I have no problems with
authentication.

> 
> Notice that the script copies the org passwd file, you have to change it
> to your needs before you run sshd in chroot and maintain it from that
> point in time, example attached.  Also note the script doesn't install a
> syslogd for the chroot environment just run it with -e and redirect the
> output, or change the script.
> 
> Hope this helps,
> Ronald
> 
> BTW: I run this on fc3, and it's late let me know what I forgot.
> 

Thanks once again for the info. Your comments are welcome.
-- 
 Collins