-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Autopush with password pushes prompt twice #274
Comments
@tilghman I have a hunch that the issue is duo to your pam stack being run twice when not using the publickey. In that case, the "password,keyboard-interactive" clause of the sshd config is being used, and each of those options will run the PAM stack. Without more details about your pam config, I can't say for sure if that's the cause, or why exactly the autopush config changes the behavior. Since |
Our pam config is (almost) identical to the recommendation on the duo_unix page. Here it is: If we comment out pam_unix.so, then password+Duo authentication fails before the Duo push is attempted. No, we cannot use just keyboard-interactive. That would allow Duo-only to be sufficient for authentication, and we are explicitly required to use two-factor (password plus Duo or publickey plus Duo) for all administrator-privileged logins. |
@tilghman Ah, I see. We have found that if your authentication requirement for ssh is Our recommendation for this use case is to implement login_duo as a ForceCommand, see https://duo.com/docs/loginduo#enable-login_duo |
I'm reading through the caveats on ForceCommand, and it scares me a bit. The point of having two-factor is to theoretically make logins more secure, not less. And the line right in the documentation is that the mitigation is to use pam_duo, not login_duo. Also, I'm rather confused at why, when we turn autopush OFF, the problematic behavior disappears. It sounds like autopush is buggy, and this should be either noted in the documentation or fixed. |
@tilghman I agree that login_duo is less desirable overall, but due to the behavior of sshd and PAM, that is the only way to allow either pubkey or password as a first factor, without trying to write a very complicated pam module that can persist state across pam invocations and/or detect the ssh context. I suspect the difference in the autopush behavior comes down to your failmode configuration. With autopush disabled, during With autopush enabled, pam_duo does not need to display the prompt and so is able to do 2FA. Then, in either case, the |
Description
When pam_duo.conf specifies autopush, and the sshd AuthenticationMethods include a combination of "password,keyboard-interactive", Duo pushes the request twice before authentication can succeed. This does NOT occur if a publickey is offered and authenticates. Also, turning off autopush similarly allows a single push to authenticate the user.
We are currently running RHEL 7 and RHEL 9, with the behavior observable on both. RHEL 7 is likely less of a concern, as it reaches EOL in under 60 days.
Expected Behavior
When autopush is turned on in combination with a password, Duo should authenticate the user after a single push.
Actual Behavior
Two pushes are sent to the user device, after which authentication succeeds.
Steps to Reproduce
Workarounds
Turning off autopush is sufficient to work here. However, we would prefer to have autopush turned on.
The text was updated successfully, but these errors were encountered: