Actually, I wanted to make something like this in SSH user
impersonation, <https://fedorahosted.org/freeipa/ticket/2356>. 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
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 <s...@redhat.com
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.
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
Freeipa-users mailing list