Thanks to Ryan@Duo for talking through some of this via chat… I was able to figure it out, also reading the approach outlined here https://github.com/duosecurity/duo_unix/issues/39 (though that approach never worked for me). I cannot swear that this does not have holes, but it works consistently in every scenario that we use.
Title
How do I 1) enable pam_duo to use passwords and 2) exclude public key authentication and 3) use both local-accounts (/etc/passwd) as well as SSSD/Kerberos integration with 2FA.
Answer
Setting up Duo Unix (pam_duo) is relatively straightforward from the documentation, and Duo provides an additional help-article at https://help.duo.com/s/article/ka070000000fzxYAAQ/2231 if you want to use passwords. However, this does not play well if you are using (in our case) SSSD, RedHat’s offering that allows you to integrate with LDAP, AD, and so on (using a Kerberos ticket from your Windows PC will bypass 2FA completely, which we also do not want). Additionally, we needed to support both AD accounts as well as local-accounts (for our remote-monitoring NOC to login), and we wanted to use 2FA for all involved.
NOTE: in this setup, the Pubkey exceptions do NOT get prompted for 2FA, but that is how we want it for this setup. We exclude those accts via the “group” option in pam_duo.conf
Follow the pam_duo instructions at https://duo.com/docs/duounix before making the following configuration changes.
Tested on RHEL6.x
/etc/ssh/sshd_config:
PubkeyAuthentication no
PasswordAuthentication yes
ChallengeResponseAuthentication yes
UsePAM yes
UseDNS no
<snip – go to end of the file>
#edits for 2FA and any PubKey auth
#add any account that IS using public-key authentication
Match User oracle,grid
PubkeyAuthentication yes
#We are using SSSD ‘ad_access_filter’ to control access,
#so need to turn off GSSAPI Auth for those AD users,
#otherwise they get passed in via Kerberos ticket and no
#password-prompt OR 2FA challenge
Match Group ssh_console_users
GSSAPIAuthentication no
/etc/pam.d/sshd: The idea is that with “pam_localuser.so”, if the user trying to login exists in /etc/passwd, skip 1 line to “pam_unix.so” which handles the auth and then falls into “pam_duo” for the 2FA. If the users does NOT exist in /etc/passwd, fall into “pam_sss.so” (SSSD) which handles the auth and then skips 1 line into “pam_duo” for the 2FA.
#%PAM-1.0
auth required pam_sepermit.so
##Duo 2FA Changes begin
#auth include password-auth
auth required pam_env.so
auth [success=1 default=ignore] pam_localuser.so
auth [success=1 default=ignore] pam_sss.so
auth requisite pam_unix.so
auth [success=1 default=ignore] /lib64/security/pam_duo.so
auth requisite pam_deny.so
auth required pam_permit.so
##End Duo Changes
account required pam_nologin.so
account include password-auth
password include password-auth
#pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session required pam_loginuid.so
#pam_selinux.so open should only be followed by sessions to be executed in the user context
session required pam_selinux.so open env_params
session required pam_namespace.so
session optional pam_keyinit.so force revoke
session include password-auth
/etc/pam.d/system-auth: basically unchanged from https://help.duo.com/s/article/ka070000000fzxYAAQ/2231 but take note how “pam_deny.so” did move positions up. Here is the top excerpt:
#%PAM-1.0
#This file is auto-generated.
#User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_fprintd.so
##auth sufficient pam_unix.so nullok try_first_pass
auth [success=1 default=ignore] pam_unix.so nullok_secure
auth requisite pam_unix.so
auth [success=1 default=ignore] /lib64/security/pam_duo.so
auth required pam_deny.so
##End Duo Changes
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
#auth required pam_deny.so
