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]
