SSH MFA Enforcement - OnePAM | Enforce Multi-Factor Authentication on Every SSH Connection

Overview

Why MFA for SSH Is Critical

Multi-factor authentication for SSH remains one of the most difficult security controls to implement at scale. Traditional approaches require configuring each Linux server individually. Configuration drift, module conflicts, and upgrade breakage make this approach operationally painful. Many organizations give up and accept SSH key-only authentication — which provides no MFA whatsoever. OnePAM eliminates per-server MFA configuration by centralizing MFA enforcement at the identity layer. When users SSH to a server, OnePAM authenticates them via your corporate IdP (Okta, Azure AD, Google Workspace), which enforces its MFA policies — Duo push, FIDO2 security keys, biometrics, TOTP, or SMS. The same MFA policies you enforce for SaaS applications now apply to SSH. No per-server TOTP seeds. No configuration drift. One MFA policy from your IdP, enforced on every SSH session across your entire fleet.

Local Agent

The agent triggers IdP MFA during SSH authentication. Users complete MFA via their phone or security key. No per-server TOTP configuration.

Gateway SSH Proxy

The gateway enforces MFA before proxying SSH connections. MFA happens at the gateway — no server-side MFA configuration needed. Works with any server.

SSH Security Risks

SSH Without MFA — The Risks

Without identity-based SSH access, these risks threaten your servers every day.

SSH keys provide single-factor authentication — if the key is stolen, the attacker has full access

Password-based SSH without MFA is vulnerable to brute-force and credential stuffing attacks

Per-server PAM MFA modules (pam_duo, pam_google_authenticator) create configuration drift and operational burden

TOTP seeds stored on individual servers are a management nightmare at scale and break on server reimages

Compromised developer laptops with SSH keys grant immediate access without MFA challenge

The Challenge

SSH Security Challenges

These are the risks organizations face with traditional SSH authentication.

Per-Server MFA Configuration

Traditional SSH MFA requires configuring each server individually. At 100+ servers, this is operationally prohibitive.

Configuration Drift

MFA configurations diverge across servers over time. Some servers have outdated settings, broken configurations, or bypassed MFA — creating inconsistent security.

TOTP Seed Management

Google Authenticator-style TOTP requires storing seeds on each server for each user. Seed management, backup, and recovery at scale is a nightmare.

User Experience Friction

Per-server TOTP is poor UX. Users must manage different TOTP entries for different servers. Push-based MFA (Duo, Okta) is better UX but complex to deploy per-server.

SSH Key + No MFA

Most organizations authenticate SSH via keys without any MFA. The key is the only factor. If compromised, there's no second challenge.

Upgrade Breakage

OS upgrades and SSH daemon updates frequently break MFA configurations. Debugging authentication on production servers is risky.

Setup Guide

How OnePAM Enforces MFA on SSH

Step-by-step guide to deploying identity-based SSH access.

1

Deploy OnePAM

Install agent on servers or deploy gateway SSH proxy. No per-server configuration required.

Agent mode: The agent triggers IdP-based MFA for SSH authentication. Gateway mode: MFA is enforced at the gateway before SSH connections are proxied. Both modes use your IdP's MFA policies.

2

Connect Your IdP's MFA

OnePAM uses your IdP's existing MFA configuration. Whatever MFA you've set up in Okta, Azure AD, or Google Workspace applies to SSH.

If your IdP requires Duo push for production systems, SSH sessions to production servers will require Duo push. If FIDO2 is required for admin access, SSH admin sessions will require FIDO2. No separate MFA configuration.

3

Define MFA Policies Per Server Group

Set different MFA requirements for different server groups or access levels.

Examples: Development servers require any MFA factor. Production servers require FIDO2 or Duo push (no SMS). Break-glass access requires biometric verification. Contractor access requires MFA on every session with no remember-device option.

4

Users SSH with MFA

'onepam ssh server.example.com' triggers IdP authentication with MFA. After completing MFA, the SSH session begins.

The MFA experience is identical to logging into any SaaS application. Users receive a Duo push, tap their FIDO2 key, or enter a TOTP code via their IdP. No SSH-specific MFA app or configuration.

5

Audit MFA Compliance

Track MFA usage across all SSH sessions. Identify sessions, users, or servers that don't meet MFA requirements.

Dashboard shows MFA method used per session, MFA enforcement rate, and any policy violations. Export reports for compliance audits.

Key Benefits

Benefits of SSH MFA Enforcement

What changes when you deploy identity-based SSH access.

Zero Per-Server MFA Config

No TOTP seeds, no per-server configuration. MFA is enforced centrally through your IdP's existing policies.

Zero per-server configuration

IdP MFA Policies on SSH

The same MFA policies you use for SaaS apps (Duo push, FIDO2, biometrics) now apply to SSH. One policy, all applications.

Consistent MFA across all access

No Configuration Drift

MFA policies are centralized in your IdP. Changes apply to SSH immediately. No per-server updates needed.

Zero drift, always consistent

Support All MFA Methods

Duo push, FIDO2 security keys, biometrics, TOTP, SMS — whatever your IdP supports. OnePAM doesn't limit MFA options.

All IdP MFA methods supported

Step-Up MFA for Sudo

Require additional MFA verification when users escalate to root via sudo. Critical commands get extra authentication.

MFA step-up for privileged ops

Compliance Evidence

Prove to auditors that 100% of SSH sessions are MFA-protected. OnePAM logs include MFA method and verification status.

100% MFA-verified SSH sessions

SSO Features

SSH SSO Capabilities

Every feature needed for enterprise-grade SSH authentication.

IdP-based MFA enforcement for SSH sessions

Support for Duo, FIDO2, biometrics, TOTP, push

No per-server MFA configuration

MFA step-up for sudo elevation

Configurable MFA policies per server group

Remember-device option for trusted endpoints

MFA bypass for break-glass emergency access

MFA compliance reporting and dashboards

Works with any SAML 2.0 or OIDC IdP

Transparent MFA — same UX as SaaS app login

Security

Zero-Day Protection Features

Enterprise-grade security controls for SSH access.

Phishing-resistant MFA (FIDO2) for SSH

MFA requirement cannot be bypassed by users

Failed MFA attempts trigger security alerts

Adaptive MFA based on risk signals (location, device)

MFA verification logging for every session

Impossible travel detection for SSH sessions

Device trust verification before MFA challenge

Integration with IdP risk engines (Okta ThreatInsight, Azure AD Identity Protection)

Real-World Scenarios

SSH MFA Enforcement Use Cases

Common scenarios where organizations deploy OnePAM SSH SSO.

1

Enterprise enforcing Duo push MFA on all SSH sessions to 500+ Linux servers without per-server configuration

2

Financial institution requiring FIDO2 security keys for SSH access to trading platform servers per regulatory mandate

3

Healthcare company enforcing MFA on SSH to ePHI servers for HIPAA compliance without disrupting clinical workflows

4

Government agency requiring PIV/CAC card MFA for SSH access to classified Linux systems via IdP integration

5

DevOps team adding MFA step-up for sudo on production servers while keeping dev servers with standard MFA

6

MSP enforcing MFA on all contractor SSH sessions to client servers with no remember-device option

Frequently Asked Questions

SSH MFA Enforcement FAQ

Common questions about SSH SSO and zero-day protection.

Can OnePAM enforce MFA without configuring each server individually?

Yes. In gateway mode, MFA is enforced at the OnePAM gateway — no server-side MFA configuration is needed. In agent mode, OnePAM delegates MFA to your IdP. There's no per-user TOTP seed management or per-server configuration.

Which MFA methods are supported?

OnePAM supports any MFA method your IdP provides: Duo push, FIDO2/WebAuthn security keys, biometric verification, TOTP, SMS, phone call, and Okta Verify. OnePAM doesn't limit MFA options — it uses your IdP's MFA capabilities.

Can I require different MFA levels for different servers?

Yes. OnePAM policies can specify different MFA requirements per server group. For example: production servers require FIDO2, staging requires any MFA, and dev allows passwordless authentication from trusted devices.

Does MFA add latency to SSH sessions?

MFA authentication typically adds 3-10 seconds (depending on the MFA method — push notification is faster than TOTP entry). Once authenticated, the SSH session has zero additional latency. Sessions can be cached to avoid repeated MFA challenges during a configurable window.

Can I enforce MFA for sudo commands?

Yes. OnePAM supports MFA step-up for sudo elevation. When a user runs sudo on a production server, they receive an additional MFA challenge. This ensures that privilege escalation requires explicit re-authentication.

What about break-glass emergency access without MFA?

OnePAM supports break-glass policies for emergency access. Designated break-glass accounts can bypass MFA requirements, but all break-glass sessions are flagged, recorded, and generate immediate security alerts for review.

Enforce Multi-Factor Authentication on Every SSH Connection