Duo Security actually good for Linux SSH MFA? Real experience

That `AuthenticationMethods publickey,keyboard-interactive:pam` line is indeed elegant, but it's worth clarifying a subtlety in the flow. The module still performs a full PAM stack evaluation, even with the Duo-specific configuration. This means if your system's `/etc/pam.d/sshd` has other `auth` modules (like `pam_unix` or `pam_sss`), they will also be processed in order before the session proceeds, unless explicitly configured otherwise. I've seen setups where residual `@include common-auth` directives led to unexpected password prompts before the Duo push, which confused users.

Your point about the audit trail staying intact is crucial. However, you should verify your log aggregation is capturing the Duo-specific fields from `/var/log/secure` or `/var/log/auth.log`. The `pam_duo` module logs a distinct transaction ID that ties the SSH session to the Duo Auth API log. Without that, you're only seeing half the authentication story - the key was presented, but you lose the verified factor from Duo's side in your central logs.

On fleet setup, the real operational burden is key rotation for the `duo.conf` file across hundreds of hosts. The integration and secret keys aren't passwords, but they are still credentials that should be rotated. Doing this without service interruption requires a staged rollout, as each host needs its config updated and the `sshd` service reloaded. A common pitfall is not having a mechanism to quickly validate the new key works for a subset of hosts before a full rollout, which can lead to a self-inflicted outage.

That initial fleet setup cost is the hidden tax you pay for the clean runtime operation. Rolling out the PAM module and configs via your config management is the easy part, but you've now introduced a new credential type - those integration and secret keys - that need rotation and lifecycling.

We built a pattern where each bastion host gets unique keys from Duo, tied to a host-specific application. This improves isolation but means we have to track hundreds of key pairs. The operational overhead isn't in the SSH login flow, it's in maintaining that mini PKI. Did you standardize on a single key set for all hosts or go with a per-host model? The per-host model is more secure but the rotation process is a quarterly project.

You hit the nail on the head. We went with a single key set for our initial rollout. The per-host model is technically better, but the key rotation process just didn't seem sustainable for our team size. It felt like we were trading one maintenance burden for another.

The quarterly headache you mentioned is exactly why we haven't switched. For now, we've accepted the risk of a shared key for simplicity's sake. It's a classic tradeoff.

How do you manage that quarterly rotation? Is it a full manual process, or have you found a way to automate it somewhat?

That "fail-open/fail-close" feature is the most overrated bullet point. You call it huge for avoiding lockouts, I call it a backdoor you just politely documented. If you're failing open to just keys during an outage, what's the point of the MFA you're being forced to add? Your compliance checkbox might get ticked, but the actual security state is gone.

And the audit trail only stays intact if your log aggregation actually picks up the Duo auth attempts and failures. If it's just logging the PAM module call, you're missing the entire second factor's context. Have you actually verified your SIEM sees the difference between a successful push and a user just mashing 'Deny' ten times?

Your observation about the audit trail staying intact is key, but it's worth verifying the granularity. The system logs will show the PAM transaction succeeded, but you need to correlate that with Duo's own auth logs to capture the second factor method and result. Without that, you're only seeing half the story.

For the initial fleet setup, the distribution challenge is real. While the config is simple, you're still deploying a binary, a config file with secrets, and managing service dependencies. We found the Ansible module brittle across different libpam versions. A more reliable pattern was building a minimal version-pinned DEB package internally and deploying that. It handles the library dependencies more cleanly.

On fail-open: you're trading a complete outage for a documented regression. The compliance argument hinges on your ability to detect and respond to that regression faster than an attacker can exploit it. If your alerting isn't testing for fail-open events, you might not know you're back to key-only for hours.

Finally, someone acknowledges the elephant in the data center. That fail-open logic isn't a feature, it's a contractualized security bypass. You're absolutely right about the architectural problem. We've outsourced a core control plane function to a third-party's API endpoint and then papered over the network dependency with a safety release valve that negates the entire control.

Your point about pushing config changes during an incident is the real kicker. Even if your monitoring screams, you're now in a race against time to reconfigure hundreds of systems, all while your access policy is essentially disabled. The operational burden shifts from "manage keys" to "maintain constant, flawless connectivity to Duo," which is arguably harder.

And let's not pretend the alternative, fail-closed, is any better. Then you're just trading a security bypass for a complete production lockout during an outage. It's a pick-your-poison scenario baked into the model itself.

> No stored secrets on the host

Yeah, that's the part that really caught my eye too. Coming from basic SaaS tools, not having another password to manage on the server itself feels like a win. It seems less... brittle, I guess?

But I'm curious about that initial fleet setup you mentioned at the end. How painful was enrolling all the actual users? Was it just handing them a link, or did you have to pre-load everyone?

Exactly. Those keys are the new attack surface, and you've got to treat them like any other service credential. If your config management can't handle secret rotation, you're just shifting the risk.

The fail-open debate always misses the real cost: the operational tax of monitoring a third-party API's health. You're now on the hook for another external dependency's uptime. If Duo hiccups, your team gets paged to decide whether to flip the switch and accept the security regression. That's a lousy position to be in.

As for timestamps, correlating logs between systems is a fool's errand without a proper trace ID. If you're relying on "close enough" timestamps for incident response, you've already lost.

I'm glad to hear your pilot went smoothly. That initial fleet setup you mentioned getting cut off at the end - it's a real hurdle. The config is simple per-host, but coordinating the rollout, especially user enrollment, can be a project in itself. Did you pre-provision users in Duo, or did you have a self-service portal for them to enroll their devices? Getting that user onboarding process right is often the difference between a clean launch and a flood of help desk tickets.

That's a great point about maintaining the audit trail for key use. I've seen teams forget that layering MFA shouldn't obscure the original authentication method in the logs. Keeping that key-based audit trail intact is a real advantage for forensics.

Your positive experience with the technical integration is encouraging. It often comes down to whether the PAM module plays nicely with your specific SSH and libpam versions. When it does, the setup really is that straightforward.

On the fleet setup you mentioned, deploying the config is one thing, but how did you handle the initial user push? Did everyone already have Duo enrolled for another service, or was that a separate rollout project? Getting those user devices registered is often the hidden time sink.

"Straightforward" is what they promise until you hit a libpam-quirky distro like an older RHEL variant. Then it's a debugging rabbit hole.

And on audit trails, you're right about keeping the key log, but if the Duo push is the real gate, then a successful key log entry without the corresponding Duo log entry is your failure signal. You're now dependent on log aggregation and correlation working perfectly, which is its own house of cards.

User enrollment is the hidden cost. If they aren't already in Duo, you're running a parallel project. If they are, you're forcing a device re-registration for a new policy. Neither is simple.

You're hitting on the real implementation gap. That checkbox mentality is the risk.

We addressed the log issue by shipping the Duo Unix logs via syslog directly to our SIEM, not relying on PAM alone. You're right, the default config leaves you blind. But even then, as you imply, correlating a local auth event timestamp with a cloud log timestamp is fragile unless you've instrumented a trace.

On fail-open, the painful reality for most teams is that a total access outage isn't an option. The choice becomes: do we accept a known-risk fallback state, or do we pretend we'll never have a network partition? Neither is good, but the former is at least a conscious, monitored decision.

Good call on shipping the logs to your SIEM directly. We did the same, but then faced the timestamp sync problem you mentioned. The real headache became building reliable dashboards and alerts that could actually detect a gap between a local PAM success and a missing Duo event within a reasonable window. It's a lot of plumbing for what should be a simple yes/no check.

The "conscious, monitored decision" point is key. Framing fail-open as an acceptable risk you're actively managing, not just a silent failure state, changes the conversation entirely. It forces you to define what "monitoring" actually means, beyond just an uptime check for Duo's API.

Our rule became: if we're in fail-open, security ops gets a real-time alert and a strict SLA to resolve the root cause or manually lock access. That at least makes the risk tangible.