_Did you try this with_
_ AuthenticationMethods publickey,keyboard-interactive_
_and_
_ ChallengeResponseAuthentication yes_
_in sshd_config?_
Yes i did and it keep requesting the password in every cases i could try
Now if the keys are provided by the id_provider
This mean that in fact sssd need another option to force push that
request to auth_provider if declared as proxy ?
This could force sssd to authenticate the ssh key by the Radius instead
of the id_provider
well both would be possible at this point which is the perfect scenario
Thank you.
On 2019-05-10 10:40, Sumit Bose wrote:
> 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]
_______________________________________________
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]
