How can I use AD credentials and Google Authenticator for SSH on Ubuntu?

November 15, 2026 4 answers
Asked by 6m+tinwhistle_829

I want Ubuntu servers to accept Windows AD credentials over SSH, with Google Authenticator as a second factor. I'd prefer not to require a browser for MFA.

Kerberos can get a ticket, but getent and id can't find the account. SSSD reports its LDAP backend as offline even though DNS resolves and the firewall allows traffic to port 636. What should I check?

Answers

b624+socketlabel_3

Start with the SSSD domain backend log rather than the PAM or NSS messages. Those often just report that the backend is offline. The more useful error here is the LDAP connection failing authentication, followed by SSSD saying it has no available LDAP servers.

A Kerberos ticket proves one part of the setup works, not that SSSD can bind to LDAP or look up accounts. Check the LDAP server address, bind or authentication settings, and the TLS configuration against the actual directory endpoint. Also check whether the configuration expects LDAPS on port 636 or LDAP with StartTLS. Allowed firewall traffic alone doesn't establish that the TLS handshake and LDAP authentication succeeded.

If it's still unclear, share the relevant SSSD domain log entries and a sanitized configuration. Remove credentials and identifying domain details first.

Reply to this answer
5a+clampwallet_381

I'd get AD identity lookup working before adding MFA. Until getent and id can resolve a domain user, adding another PAM component will make it harder to tell which layer is failing. Test SSH authentication after lookup works, then add the one-time code requirement.

Reply to this answer
6u+parcelspanner_327

Google Authenticator can provide time-based codes through a PAM module, so a browser isn't inherently required for that part. You'll need to configure both PAM and SSH to require the intended factors, then test the actual prompts rather than assuming that installing the module enables MFA.

Keep an existing administrative session open and have a separate recovery path while testing. A mistake in PAM or SSH settings can lock everyone out.

c.812+mailgauge:

Also check how users will enroll and recover their code secrets before requiring the second factor across all servers.

Reply to this answer
p.418+mailnotch_6

If maintaining the AD and PAM integration on each server becomes too much work, there are access management products worth evaluating, including Userify. Check how any alternative handles AD authentication, MFA prompts, enrollment, and recovery before treating it as a replacement.

Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions