SSSD with SSH key auth + MFA with Radius server

[Nerigal]

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

[Sumit Bose]

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 -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  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/[e-mail]...

[Nerigal]

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
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 -- sssd-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > 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/[e-mail]...
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  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/[e-mail]...

[Sumit Bose]

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 -- sssd-users(a)lists.fedorahosted.org
>  >> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  >> 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/[e-mail]...
>  > _______________________________________________
>  > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  > 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/[e-mail]... 
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  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/[e-mail]...

[Nerigal]

Hi, 

Never heard of PAM acting any how in the authentication mechanism with
using SSH key. 

im using /usr/bin/sss_ssh_authorizedkeys to authenticate SSH key and so
this is a sssd module right ?  

and this binary leads the auth mechanics to sssd using the configuration
in sssd.conf 

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 

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 -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  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/[e-mail]...
> _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  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/[e-mail]... 
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  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/[e-mail]... 
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
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/[e-mail]...

[Sumit Bose]

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 -- sssd-users(a)lists.fedorahosted.org
>  > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  > 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/[e-mail]...
> _______________________________________________
>  > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  > 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/[e-mail]...
>  
>  > _______________________________________________
>  > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  > 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/[e-mail]...
>   _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  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/[e-mail]... 
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  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/[e-mail]...

[Nerigal]

_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 -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  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/[e-mail]...
> _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  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/[e-mail]... 
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  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/[e-mail]... 
 
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
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/[e-mail]...


>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  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/[e-mail]... 
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
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/[e-mail]...