On Wed, Mar 25, 2009 at 10:43:54PM -0700, Michael Thomas wrote:
> How can I configure pam to use two separate access.conf files, one for
> admin ssh access and one for cvs ssh access? Or is there an alternate
> way of accomplishing this?
pam is more about deciding whether you are allowed to log in than it is
about deciding what you can do once you are in.
in the past, i have addressed use cases like yours with a few different
approaches.
1. ssh key auth can be augmented with command="...". i forget what
tunneled cvs looks like, but i use this for my svn users and it works
great. however, a big part of why it works great is that the command to
run is always the same (the svn client talks to the server over the
tunnel, not via command line options.) from .ssh/authorized_keys:
command="svnserve -t -r <repo_root> --tunnel-user schmolli",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss [ssh pub key]
the big downsides to this approach are that you can only run a single
command per ssh key (though you can specify multiple keys per user) and
that if the user can figure out how to overwrite the authorized_keys
file, they can unlimit their access.
2. replace the user's shell with something that will only run commands
off of a whitelist. i have always just hacked this together myself, it
only takes about 20 lines of code. if i had to do it again today, i
would spend a lot more time looking for some open source project that
had had more eyes on it.
there is a significant issue with this approach, which is that the
whitelisted commands have to be very carefully vetted so as to not give
out more access than you intended. for example, vi can be used to
execute arbitrary commands, so putting it in the whitelist obviates the
entire purpose of having one. (maybe--if you are lucky, it will execute
commands via ${SHELL} -c.) you can alleviate this by chrooting your
users into a directory tree that only contains the commands they are
allowed to execute. not sure how well chroot will work for you since
your cvs tree would probably have to be inside the chroot.
3. creative chrooting. this leads to configurations that can be
confusing and hard to maintain, but it does work great for cases where
you absolutely need /bin/bash to be two different shells for two
different users (/chroot/bin/bash can be a hardlink to /bin/nologin.)
if you are feeling really brave, you could even use pam_chroot to change
pam's config files out from under it. a configuration like that would
be frail, though, and completely inappropriate for a production
environment.
--
Ed Schmollinger - schmolli@xxxxxxxxxxxxxx - http://frozencrow.org/
Attachment:
pgpjHAP7nCROa.pgp
Description: PGP signature
_______________________________________________ Pam-list mailing list Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
