Actually, I wanted to make something like this in SSH user impersonation, <>. My idea was to allow overriding of authorized_keys options in impersonation rules.

In your case, you could have a special user account "tunnel" that would be used to access the tunnel and set up impersonation so that members of group "tunnelusers" could impersonate user "tunnel" with authorized_keys options command, permitopen, no-agent-forwarding and no-x11-forwarding overrided. That way, any user in the "tunnelusers" group would be able to log in with their normal public keys (with no authorized_keys options) as user "tunnel" and have authorized_keys options set to the needed values by the impersonation rule.

Of course, that would work only with SSH public key authentication.

BTW, if the tunnel is provided only by a single or a small number of systems, you can configure sshd on these systems to do what you want without using authorized_keys options (see man sshd_config, directives ForceCommand, PermitOpen, AllowAgentForwarding, X11Forwarding and possibly Match).


On 17.12.2012 16:30, Albert Adams wrote:
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 management.


On Mon, Dec 17, 2012 at 9: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
     > of doing this via a HBAC rule.  If I accomplish this with
     > authorized_keys then the user is restricted across the board and
     > 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

Jan Cholasta

Freeipa-users mailing list

Reply via email to