On Fri, May 10, 2019 at 08:46:00AM -0400, Nerigal wrote:
> Hi,
>
> Never heard of PAM acting any how in the authentication mechanism with
> using SSH key.
Yes, because they are completely unrelated.
>
> im using /usr/bin/sss_ssh_authorizedkeys to authenticate SSH key and so
> this is a sssd module right ?
Yes, sss_ssh_authorizedkeys is part of SSSD
>
> and this binary leads the auth mechanics to sssd using the configuration
> in sssd.conf
no, as said above PAM and SSH public key authentication are completely
unrelated.
sss_ssh_authorizedkeys talks to the SSSD ssh responder (sssd_ssh
process) configured in the [ssh] section of sssd.conf and if 'ssh' is
not listed in the 'services' list in the [sssd] section of sssd.conf the
ssh responder is not started and sss_ssh_authorizedkeys would return no
key. The ssh responder get the ssh public key data form the id_provider
configured for the backend.
PAM authentication is handled the SSSD PAM responder (sssd_pam process)
and configured in the [pam] section of sssd.conf. The PAM request
(authenticate, access control, etc) are forwarded to the auth_provider
configured in the backend. So SSSD will only access the proxy_pam_target
while handling PAM requests.
>
> Other thing that make me thing this isn't right is that i first tried to
> put the
>
> pam_radius_auth.so lib into /etc/pam.d/password-auth
>
> And i found that it change nothing to the ssh auth with Kay... still
> successful without any negotiation with the Radius
>
> so i tried with sshd directly...
>
> pam_radius_auth.so lib into /etc/pam.d/sshd
>
> with auth required pam_radius_auth.so
Did you try this with
AuthenticationMethods publickey,keyboard-interactive
and
ChallengeResponseAuthentication yes
in sshd_config?
I still would recommend keyboard-interactive instead of password because
iirc with password with ssh client will ask for a password
unconditionally while with ChallengeResponseAuthentication the PAM
conversation is send to the client. So if you add pam_radius_auth.so
near the beginning of /etc/pam.d/password-auth so that no other PAM
module can ask for a password you might be able to call pam_radius_auth
without a password prompt.
HTH
bye,
Sumit
>
> and
>
> account required pam_radius_auth.so
>
> But the behavior was the same... it ignored both and the radius server
> never received any packets but the authentication was successful and
> this is a normal and expected behavior
>
> the problem is that the SSH Keys authentication is leaded by
> /usr/bin/sss_ssh_authorizedkeys and this require SSSD to allow Keys over
> LDAP object ( otherwise SSH would not be able the authenticate the user
> since the pubkeys doesn't exist locally on the server ) but still avoid
> the negotiation with the radius, this negotiation require SSSD to
> "pass-by" the pam stack with the proxy_pam_target
>
> So with the test i made, it says that ssh key authentication with
> /usr/bin/sss_ssh_authorizedkeys retrieve the needed information from
> sssd.conf directly with the LDAP alternate attribute and LDAP AD user
> object path to make the authentication possible without any negotiation
> with the Radius which also say that proxy_pam_target is ignored.
>
> So sssd behavior need to be modified to add an option to enforce using
> proxy_pam_target even with the use of the following options
>
> ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities
> ldap_user_ssh_public_key = altSecurityIdentities
> ldap_use_tokengroups = True
>
> On 2019-05-10 01:26, Sumit Bose wrote:
>
> > On Thu, May 09, 2019 at 09:45:46PM -0400, Nerigal wrote:
> >
> >> Hi,
> >>
> >> keyboard-interactive is for OTP only like the old google authenticator
> >>
> >> I use AMFA from Azure which require no code to be typed at screen
> >>
> >> So this option is irrelevant to the problem
> >>
> >> The problem is that sssd skip the pam stack with ssh key, i think it
> >
> > Hi,
> >
> > it is not SSSD skipping PAM here but sshd. SSSD can only be involved if
> > the service needing authentication, sshd here, call pam_authenticate.
> > With publickey authentication sshd usually skips this because the user
> > is already authenticated. So you have to make sshd call pam_authenticate
> > even in the case it already authenticated the user with a public key.
> >
> > HTH
> >
> > bye,
> > Sumit
> >
> > could be a good plus value to add an option to sssd to stick to PAM
> >
> > even with alternate authentication from Active Directory.
> >
> > The work around applied at the moment is to use AuthenticationMethods
> > "password,publickey"
> >
> > We have multiple jumpbox scenario to go trough but only the first
> > jumpbox require 2FA ( MFA from Azure )
> >
> > So using SSH Key managed in Active Directory was a must, otherwise users
> > would have been obligated to type creds at every jumpbox which make
> > irrelevant the use of ssh gateway to me
> >
> > So the problem faced was that the first must use password auth to go
> > trough PAM stack to trigger the MFA
> >
> > and all other jump must be SSH Key aware to facilitate everyone lives
> > here...
> >
> > now the issue was that if you only allow password auth at the first
> > Gateway.. all the next up can't authenticate using ssh-agent forwarding
> >
> > so the first hop has to authenticate with the password + MFA as well
> > with the ssh key.
> >
> > Like i said This is a work around and not a decent solution. With the
> > possibility of forcing SSSD to go trough PAM with the SSH Key validation
> > though Active directory
> >
> > it make possible the option of password less authentication with MFA
> > which is the targeted functionality.
> >
> > On 2019-05-09 10:36, Sumit Bose wrote:
> >
> > On Thu, May 09, 2019 at 07:55:31AM -0400, Nerigal wrote:
> >
> > Hi,
> >
> > I could make sssd work fine with domain authentication with Radius
> > server + Azure MFA through SSH gateway using password
> >
> > So the user enter his creds and then get to prompt on his phone to
> > accept or reject the authentication
> >
> > Everything work as expected so far
> >
> > The problem comes with SSH keys ...
> >
> > i tried the alternate authentication in Active Directory adding users
> > SSH keys in altSecurityIdentities user object attribute
> >
> > and configuring
> >
> > ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities
> > ldap_user_ssh_public_key = altSecurityIdentities
> > ldap_use_tokengroups = True
> >
> > in sssd.conf file
> >
> > and its actually working too well...
> >
> > The "too well" is that it looks like as soon as the user has a working
> > ssh Key in Active Directory, SSSD ingore the configuration
> >
> > auth_provider = proxy
> > proxy_pam_target = sssdproxyradiusauth
> >
> > Note *
> >
> > sshd_config is configured with
> >
> > AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
> > AuthorizedKeysCommandUser root
> >
> > So is there a way to make SSSD always pass by the Radius regardless of
> > the auth mechanic ?
> >
> > May be the "proxy bypass" with SSH key come from
> > /usr/bin/sss_ssh_authorizedkeys i can't tell at this point
> > Yes, most probably. /usr/bin/sss_ssh_authorizedkeys will send the ssh
> > key read by SSSD from the AD user object to sshd so that sshd can to
> > public key authentication. This is the same as if you have out the ssh
> > key into the .ssh/authorized_keys file in the user's homes directory
> > only that it is centrally managed in AD.
> >
> > If you want to tell sshd to use both publickey and keyboard-interactive
> > authentication together please see AuthenticationMethods in man
> > sshd_config for details.
> >
> > HTH
> >
> > bye,
> > Sumit
> >
> > _______________________________________________
> > sssd-users mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedorahosted.org/archives/list/[email protected]
> > _______________________________________________
> > sssd-users mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedorahosted.org/archives/list/[email protected]
>
> > _______________________________________________
> > sssd-users mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedorahosted.org/archives/list/[email protected]
> _______________________________________________
> sssd-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/[email protected]
> _______________________________________________
> sssd-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/[email protected]
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
