An HBAC extension would certainly be appreciated. I'm not sure how other
organizations are setup but in our environment we don't give shell access
unless absolutely necessary and we use a lot of SSH tunneling with target
services bound to localhost. If I can figure out the correct syntax to get
the perl command added to the users public key in IPA (as Honza suggested)
then that will provide a work around for the time being. Ultimately it
would be awesome to have the same level of granularity that the local
authorized_keys file allowed while reaping the benefits of centralized
On Mon, Dec 17, 2012 at 9:36 AM, Simo Sorce <s...@redhat.com> wrote:
> On Mon, 2012-12-17 at 09:07 -0500, Albert Adams wrote:
> > Thank you for the responses. I was initially attempting to set this
> > value via the web UI and if I entered anything other than the hash
> > value of the user's public key it would get rejected. After thinking
> > about your response I realize that I really need to determine a method
> > of doing this via a HBAC rule. If I accomplish this with
> > authorized_keys then the user is restricted across the board and would
> > not be able to gain a shell on any system whereas HBAC would allow me
> > to restrict thier access as needed. We currently require users to
> > tunnel over SSH to gain access to certain sensitive web apps (like
> > Nessus) but those same users have shell access on a few boxes.
> > Thoughts??
> One thing you could do is to use the override_shell parameter in sssd.
> However this one would override the shell for all users so just
> putting /sbin/nologin there would not work if you need some users to be
> able to log in (if you care only for root logins it would be enough).
> However you can still manage to use it to point to a script that would
> test something like whether the user belongs to a group or not, and if
> so run either /bin/bash or /bin/nologin
> This seem like a nice feature request for FreeIPA though, maybe we can
> extend HBAC to allow a special option to define a shell, maybe creating
> a special 'shell' service that sssd can properly interpret as a hint to
> set nologin vs the actual shell.
> Dmitri, should we open a RFE on this ?
> Simo Sorce * Red Hat, Inc * New York
Freeipa-users mailing list