[Freeipa-users] Allow IPA users to create SSH tunnel with no shell

[Jan Cholasta]

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 
possibly Match).

Honza

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.
>
> Albert
>
>
> On Mon, Dec 17, 2012 at 9:36 AM, Simo Sorce <simo at redhat.com
> <mailto:simo at 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.
>
>     --
>     Simo Sorce * Red Hat, Inc * New York
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>


-- 
Jan Cholasta