SSH with Duo and AD - behave like SSO?

[Shane_Wolfe]

Hi all,

Brainstorming here…

Deploying Duo to many Mac and Linux systems. There is pervasive use of SSH in the environment, much of it automated by using SSH keys as one would expect.

I would treat the keys as “untrusted” since they are currently completely user managed. Switching to trusted auth, I’d use AD as the first factor, and Duo as the second. This ensures a quick cleanup of a newly departing user without having to go back and sweep up keys.

The issue with this is that it pretty much breaks automation.

What are folks doing (outside of kerberos) to make SSH behave sort of like an SSO login? What I’d like to see is a capability to log in with AD/Duo once and have that session live for x number of hours before requiring re-authentication. This I think would be a good middle ground to support automation within reason and still keep it manageable from a security/risk perspective.

[JasonP3]

I’m not sure what you mean by ‘automation’ in your environment but I have implemented a solution for our environment that may or not be helpful.

We wanted to use two factor authentication for logins to routers (and other SSH enabled devices). However, we have tools that carry out automated tasks via SSH logins (and so wouldn’t work with two factor authentication).

What we did was create a separate AD account that was valid for SSH logins (and nothing else) but didn’t have an associated DUO account. We then configured the DUO application (RADIUS in this case) to ‘Allow New Users’. In this way, allowed AD accounts that don’t have an associated DUO account are allowed without 2FA. This specific user account is only know by system admins and only used in automation tools and never used for interactive logins. It isn’t a perfect solution (what is when dealing with security?) but does allow us to improve general security by implementing 2FA for user SSH logins without breaking our automated logins.

[rynothopter]

JasonP’s approach is totally valid, however, setting the new user policy to ‘Allow’ does create a risk of bypassing the 2FA requirement for ANY unknown user accounts (from Duo’s perspective) for systems that share the same application policy (ikey/skey). Using the ‘groups’ option within the pam_duo.conf to enforce or exempt 2FA on specific users logging into the system could help mitigate that risk. The tradeoff is that you would have to manage this on each system: https://help.duo.com/s/article/2225

In regards to session/SSO timeouts, Duo is no longer in the SSH session workflow after the authentication process, so this is not something we can really help solve with our PAM module. We just released the ability to protect SSH logins using our Network Gateway (requires our Beyond edition). Using the Network Gateway does provide an option to configure a “session duration”. More information about the Duo Network Gateway and SSH here.

Hope this helps!

[Shane_Wolfe1]

Thanks all!

I think our approach going forward will be to adopt the use of Kerberos in more of the environment. This allows a common-sense approach without hitting the user with constant 2FA requests. If the user doesn’t have a valid krb ticket, they will have to 2FA into every box.

[Shane_Wolfe1]

We have our ssh configuration most of the way there…

Has anyone successfully set up kerberos so that kinit will also prompt for Duo 2FA?