Open-source alternative to Duo Unix for Linux SSH

Replacing Duo Unix for SSH: the short answer on open-source options

If your Duo renewal is coming up, or your security policy now requires SSH authentication to stay on premises, the short answer is this: privacyIDEA's PAM module fits teams that want a broad set of factors, while FreeIPA's built-in OTP fits teams that already run, or plan to run, an identity management realm for their Linux estate. Both replace pam_duo for SSH and local logins, and both keep the second-factor check inside your network. The choice depends less on which factor you need today and more on where your user directory and certificate and Kerberos services will live over the next few years. Duo Unix's recommended pam_duo module contacts Duo's service over TCP port 443 on every authentication, so any server that uses it needs outbound access to Duo's cloud. Replacing it means the MFA decision happens on a server you operate. privacyIDEA integrates with Linux through its PAM module and reads users from your existing LDAP or Active Directory through its user ID resolvers, so the decision stays between your servers and your directory. FreeIPA handles OTP checks inside its own Kerberos-based realm and can proxy them to an existing RADIUS server if you have one. Before choosing, confirm three things in your own environment: which factors your users actually carry (hardware keys, TOTP apps or push), whether your servers can reach an internal MFA service in every network segment, and what Duo Unix's failmode setting currently does on your fleet. Duo Unix defaults to safe, which lets users in with primary authentication only when Duo cannot be reached, so your replacement design must state explicitly what happens when the MFA service is down, and that behavior should be approved by your security owner before any server changes.

Which Duo Unix capabilities map to privacyIDEA and FreeIPA

This table maps each Duo Unix behavior, from pam_duo and login_duo to push, passcodes and failmode, against privacyIDEA's PAM module and FreeIPA's built-in OTP. Read the cells as the starting point for a proof of concept on your own distribution, because the gaps and the fallback behavior decide how the rollout is staged.

Duo Unix capability	privacyIDEA PAM module	FreeIPA OTP
pam_duo for SSH and local logins	PAM module for Linux logins, to be confirmed for your SSH and PAM stack	OTP checks run through SSSD and the Kerberos KDC, to be confirmed for your SSH and PAM stack
Passcode entry (HOTP and TOTP)	TOTP and HOTP supported through its own app or standard authenticator apps	HOTP (RFC 4226) and TOTP (RFC 6238) supported, including software and hardware tokens
Duo Mobile push approval	Push supported, but requires the privacyIDEA Authenticator app	Not listed in the supplied FreeIPA OTP capabilities, so plan for passcodes instead
login_duo fallback where PAM cannot be used	No direct equivalent confirmed for this use case, so test on each target host	No direct equivalent confirmed for this use case, so test on each target host
Hardware keys and smartcards	FIDO2, WebAuthn, PIV and x509 smartcards supported, SSH keys also listed	Hardware OTP tokens such as YubiKeys supported, FIDO2 and smartcards to be confirmed
Failmode safe (primary login only if MFA is unreachable)	Depends on how the PAM configuration handles an unreachable server, to be confirmed in testing	Depends on SSSD and KDC configuration, so confirm the offline and unreachable behavior in testing
Reachability over TCP 443 to a vendor cloud	Runs on your own servers, so no outbound path to a vendor cloud is needed	Runs on your own servers, so no outbound path to a vendor cloud is needed
Fail open when the configuration file is missing	Configuration handling to be verified, including what happens when the PAM file is absent	Configuration handling to be verified, including sssd.conf and PAM service files

privacyIDEA PAM module or FreeIPA OTP: which fits which estate

This tab suits organizations whose users already live in LDAP or Active Directory and whose Linux servers authenticate against that directory, but who want a second factor that Duo Unix used to provide. privacyIDEA fits here because it sits beside the directory rather than replacing it. Its PAM module handles SSH and local logins, and its user ID resolvers read accounts from LDAP, including Active Directory, so you do not have to copy identities into a new store.

PAM module: the privacyIDEA PAM module is installed on each Linux host and checks the second factor against the privacyIDEA server, which is the component that replaces the pam_duo step in your PAM stack.
Factors: FIDO2 and WebAuthn keys, TOTP and HOTP apps, push notifications through the privacyIDEA Authenticator app, SSH keys, and PIV or x509 smartcards are all supported, so you can match factors to user groups.
Resolvers: LDAP or AD resolvers keep user lookups in the directory you already maintain, and the SCIM and SQL resolvers cover other stores.
Licensing: privacyIDEA is licensed under AGPLv3. The privacyIDEA Enterprise Edition is available from NetKnights if you want a commercial subscription with vendor support.

Confirm with your directory team how service accounts bind to LDAP and whether your Active Directory schema lets privacyIDEA read the attributes it needs for enrollment.

What happens to logins when the MFA service is down

Duo Unix decides what a login does when the MFA service cannot be reached through its failmode setting, and the default is safe. In that state, the user is allowed to log in with primary authentication only, so a password or key still gets in while the second factor is skipped. Duo Unix also fails open if its configuration file is missing, which is a different failure from an unreachable service and is easy to miss in a fleet review. Before you replace Duo Unix, record the failmode value and the configuration file path on every host, because those two settings describe what your current fleet does today. Confirm the exact behavior against the current Duo Unix documentation for your package version rather than relying on memory.

Moving to privacyIDEA's PAM module or FreeIPA's OTP support does not carry those defaults over automatically. You need to decide four things explicitly: whether any fallback to primary-only login is acceptable (and for which groups), how a missing or unreadable PAM configuration is handled, what happens when the OTP service or its replica is unavailable, and which accounts can still log in when the second factor is absent. Protect against accidental fail-open by pinning the PAM stack in configuration management, alerting when the PAM files change, and checking that the service fails closed when its own configuration is missing. Keep at least one break-glass account per host or host group, stored with its own controlled second factor and used only under a logged procedure, and monitor authentication failures and MFA timeouts so that a silent fallback shows up in your logs. Test each of these behaviors on a staging host before the rollout starts. Stop the MFA service, block its network path, remove or corrupt the PAM configuration in a test copy, and record what a login returns in each case. Confirm the results in your chosen PAM configuration for your distribution, because the module names, control flags and defaults in the PAM stack determine the outcome. Only after those tests pass should you roll the change across the fleet in stages, keeping the old configuration available until the new failure behavior has been observed in production.

Risks to control when rolling the change across a server fleet

Replacing pam_duo across many Linux hosts is mostly a sequencing problem: each host can lock someone out if its PAM stack, network path or enrollment data is wrong. The cards below cover the risks that tend to surface during a fleet change and the checks to run before each stage.

Lockout from an untested PAM stack

A PAM edit that is wrong on the first host can stop every SSH login to it, including the administrators who would fix it. Test the new stack on a non-production host, keep an already-open root session on each host during the change, and confirm a second login works before closing it. Check the sshd and sudo PAM files in separate sessions after every edit.

Configuration drift across hosts

Hosts that were built at different times often carry different PAM files, sshd_config settings and Duo configuration paths, so a single change behaves differently across the fleet. Inventory each host's PAM and SSH configuration first, and manage the target state with one configuration management tool so that the rollout is a repeatable change rather than a set of manual edits.

SSH keys and sudo rules tied to the old module

Some accounts may depend on the Duo prompt for SSH key logins, sudo elevation or service accounts that automation uses. Review the sudoers rules and the PAM services that call pam_duo, and decide which accounts keep a second factor, which move to key-based controls and which need an exception documented in advance.

MFA service reachability from each segment

Duo's Unix agent reaches Duo's cloud over TCP port 443, but a privacyIDEA server must be reachable from each network segment on the protocol the PAM module uses. Test that path from every segment, including bastions, jump hosts and isolated zones, before you change any host in that segment.

Enrollment gaps for Duo Mobile users

Users who only have the Duo Mobile app enrolled may have no working factor in the new system after cutover. Before the change, list users without a supported factor, enroll them in privacyIDEA, and confirm that push, TOTP or hardware tokens work for each of them, so the first login after cutover does not depend on the help desk.

A tested rollback path

A rollback needs more than a backup copy of the PAM files, because the Duo failmode behavior and the new MFA service's availability both affect whether users can log in during the reversal. Keep the original PAM and SSH configuration in version control, write the revert steps for each host group, and rehearse the revert on a test host so the team has done it before it is needed.

Moving SSH logins from Duo Unix to a new MFA module

This sequence moves SSH and local Linux logins off pam_duo and login_duo onto a self-hosted second factor, with each host verified before the Duo configuration is removed.

Inventory every host running Duo Unix
The Linux administrator lists each server where pam_duo or login_duo is installed, notes whether it protects SSH, console or sudo logins, and records the PAM stack files it edits, such as the SSH and sshd service files under /etc/pam.d. Include login_duo hosts separately, because they do not use PAM and need their own plan. The inventory is complete when every host has an owner, a login path and a note on its fallback behavior. Confirm the failmode setting on each host, since the default is safe and a missing configuration file fails open.
Export users and enrollments from Duo
Using the Duo admin console or the Admin API, the administrator exports the user list, phone and hardware token assignments, and the integrations that reference Duo Unix. Check which of these reads your plan allows before you rely on them, because API access and rate limits vary by plan. Store the export in a controlled location, since it contains personal and device data. The step is done when the record count matches the number of Duo users tied to those hosts.
Resolve users from LDAP or Active Directory
The identity team points privacyIDEA at the directory that already holds the accounts, using its LDAP resolver for Active Directory or any LDAP service, or, if the target is FreeIPA, runs the ipa migrate-ds command to bring in users and groups. Kerberos attributes are regenerated by FreeIPA and are excluded from that migration. Sudo and HBAC rules do not migrate this way and must be recreated manually from LDIF. The step is done when a test login resolves the same user IDs that Duo used.
Pilot on a non-production host with rollback
Choose one non-production Linux host and add the new PAM module alongside the existing Duo configuration rather than deleting it. Keep an active root session open while testing, and confirm that a second session can still log in after each change. Write down the exact files changed and keep copies so rollback is a restore of known files. The pilot is complete when a test user logs in with the new factor, a forced failure of the new service leaves the rollback path working, and the result is recorded.
Enroll users before cutover
Before any production host changes, users register their second factor with the new system, using standard TOTP or HOTP apps, hardware tokens, or the privacyIDEA Authenticator app for push. Hardware token seeds can be imported in the supported formats, such as OATH CSV, if you have the seed files. Confirm each user has at least one working factor and a documented recovery method. The step is done when enrollment coverage for the hosts in the first wave is confirmed by the help desk, not assumed.
Switch hosts in waves
Move production hosts in small groups, starting with low-impact systems, and apply the same PAM change and verification steps used in the pilot to each wave. Confirm that failure behavior on each wave matches your policy, since a self-hosted MFA service that is down also blocks logins unless you configure a fallback. Keep the Duo configuration in place on hosts not yet switched. The wave is complete when logins succeed, the audit logs show the new factor being checked, and no unexpected lockouts appear.
Retire Duo Unix configuration last
After every host in the inventory has passed verification and has run for a period your change policy sets, remove pam_duo or login_duo, its configuration file and its PAM references, then uninstall the package. Remove or disable the Duo integration and the related API credentials once no host references them. Record the final state in the change log. The step is done when the inventory shows zero Duo Unix hosts and the Duo integration has no remaining active dependencies.

Keeping Duo for other logins while Linux SSH moves

Most teams do not switch every Duo use case at once. A common pattern is to move Linux SSH first, because it is contained within server administration, and leave Duo in place for web single sign-on, VPN access or Windows logons until those flows have their own plan. A privacyIDEA PAM module can sit beside Duo during this period, since each server's PAM stack decides which second factor it calls. Before any server changes, list every flow that currently uses Duo and confirm which ones will stay on Duo for now, so nobody is surprised when a single user is challenged by two systems.

The main risk in a parallel period is the user-identity link. If privacyIDEA resolves users from the same Active Directory or LDAP directory that Duo's enrollments reference, one account maps to one username across both systems. If privacyIDEA instead holds its own user list, the same person can end up with two conflicting enrollments, for example two TOTP seeds or a token registered under a different login name. Decide which directory is the source of truth for usernames, check that the names match exactly in both systems, and confirm with your own environment team how privacyIDEA's user ID resolvers will read that directory before enrolling anyone.

privacyIDEA also offers a RADIUS integration for VPNs and network devices and an identity provider plugin for Keycloak, so a longer-term plan does not have to remain a mix of two MFA platforms. Note which Duo flows would move to privacyIDEA through these routes and which need separate work, and ask the vendor and your integrator to confirm the supported versions for each. Treat the parallel state as a planned phase with a named end date, not an indefinite arrangement, because two MFA systems double the enrollment and help desk questions users bring in.

Questions buyers ask before replacing Duo Unix on Linux servers

What drives the cost of replacing Duo Unix on Linux servers?

The cost is set by who you pay for what: the software licence, the servers that run the MFA service, the high availability design, implementation labor and the help desk time that enrollment creates. privacyIDEA is licensed under AGPLv3, so there is no per-user licence for the open-source edition, but an optional Enterprise Edition subscription is available from NetKnights. FreeIPA is GPL-3.0-or-later with no paid edition of its own. Recurring costs include servers, patching, monitoring, SMS and hardware tokens if you use them. One-time costs include design, integration with your directory and rollout across hosts. FreeIPA's deployment guidance calls for at least two to three replicas in each datacenter, so budget for that redundancy. Ask any partner or vendor for a written quote that separates these components.

How long does a Duo Unix replacement take, and what sets the timeline?

The timeline depends on the number of hosts, how many directories you must connect, how many distinct login paths exist (SSH, console, sudo, local logins) and how many users need a new factor enrolled. Hardware token imports, sudo and access rules, and change approval cycles often take longer than the software setup. No duration is fixed in this guide, so ask for a timeline in the written scope and check it against your own change calendar. A pilot on a small group of non-production hosts usually shows which of these factors dominate in your environment.

Can an in-house team replace Duo Unix without outside help?

Yes, if the team has experience with PAM configuration, Linux directory services and MFA enrollment. The work involves PAM stack changes, directory integration, token management and a staged rollout, and an error in the PAM stack can lock administrators out of servers. Teams without that background often choose to bring in outside help for design and rollout, and keep operations in-house. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms in your own infrastructure, typically under a fixed scope agreed in writing before work starts. Whichever route you take, keep a tested recovery path on every host before you change it.

What does the team need to provide before a Duo Unix migration starts?

The project needs four inputs from your side:

Directory access: a service account and read access to the LDAP or Active Directory store that holds the users, with a clear view of which groups may log in to which hosts.
Host inventory: a list of every server, its operating system version, how users reach it (SSH, console, sudo) and whether pam_duo or login_duo is in use today.
Change windows: approved maintenance periods and a rollback owner for each host group.
Token and user data: a current export of Duo users and any hardware tokens, so enrollment can be planned before Duo access ends.

Agree on who signs off each stage and how emergency access will work before the first host changes.

Is FreeIPA or privacyIDEA the better fit for replacing Duo Unix?

It depends on whether you need a new identity system or only a second factor. privacyIDEA fits when you already have a directory and want an MFA service: it has a PAM module for Linux, supports FIDO2, TOTP, HOTP, push and smartcards, and reads users from LDAP or Active Directory. FreeIPA fits when you are building a Linux identity domain: it combines 389 Directory Server, MIT Kerberos, Dogtag and SSSD, and provides OTP through HOTP and TOTP tokens, including YubiKeys. FreeIPA's OTP support is narrower than privacyIDEA's factor range, so check the factors your users need. FreeIPA also requires its own directory design, which is a larger change than adding MFA to existing hosts.

How should a Duo Unix replacement handle the fail-open risk?

Start by checking what Duo does today. Duo Unix's failmode defaults to safe, which lets users log in with primary authentication only when Duo cannot be reached, and it fails open if its configuration file is missing. Your replacement should have a clear, documented behavior when the MFA service is unavailable. Make the choice deliberately: keep MFA mandatory for administrative access, use a local break-glass account protected by a separate control, and monitor the MFA service with alerts. Test an outage on a non-production host before the cutover, and confirm the behavior with the vendor or project documentation for the exact version you deploy.

How DeployOpen scopes and delivers an SSH MFA replacement

An SSH MFA replacement touches sshd, PAM, directories and every server in the fleet, so the work is defined before it starts. The cards below cover what DeployOpen puts in writing, where the work runs, and what the client keeps after handover.

Written scope for hosts and PAM

The scope lists which hosts, distributions and PAM service files are in the change, including sshd, sudo and console logins if they are included. It also names which logins keep primary authentication only and which require a second factor. Ask for the host inventory and the list of PAM services to be confirmed in writing before any pilot host is touched.

Directory and resolver design

The scope covers where users come from, such as an existing LDAP or Active Directory server, a FreeIPA domain, or a privacyIDEA user store, and how UIDs and group membership map to the Linux hosts. Identity source decisions drive most of the later rework, so they are agreed before enrollment begins. Confirm which directory is the source of truth for account lifecycle.

Rollback and failure-mode tests

Every host change includes a documented rollback path and a break-glass account that works without the MFA service. The test plan checks what happens when the MFA service is unreachable, when the configuration file is missing, and when a user has no enrolled factor. Ask for these results to be recorded per host group before rollout expands.

Hardening inside your environment

Work runs in your own cloud accounts, data centers or air-gapped networks, with access granted to the people you name. Hardening covers service accounts, TLS between PAM and the MFA server, file permissions on secrets, and restricted administrative paths. Confirm where logs and seed material are stored before any token data is imported.

Backup, documentation and retainer support

The delivery includes backup of the MFA and directory components and runbooks for enrollment, lockout recovery and host onboarding. Ongoing support, upgrades and continuous testing are available as a retainer after handover. Ask whether the runbooks cover your own on-call staff, since they will run the fleet after the project closes.

Compliance evidence, not audit reports

DeployOpen prepares configuration records, access controls and test evidence that your assessors can review for SSH access control. DeployOpen does not issue audit reports, attestations or certifications, and independent auditors make that determination. Confirm early which control areas your assessor expects to see evidence for.