On 12/17/2012 09:36 AM, Simo Sorce 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.
> 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 ?
OK , RFE would make sense.
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
Looking to carve out IT costs?
Freeipa-users mailing list