AuthFI PAM

SSH without shared keys.
MFA on every login.

AuthFI PAM replaces SSH keys with identity. MFA enforcement, role-based sudo, session recording, automatic provisioning and deprovisioning.

Available on Pro and above. See pricing

Start free Read the docs

The mechanism

No key in authorized_keys. An identity on every login.

Classic SSH trusts a long-lived public key sitting in each host's ~/.ssh/authorized_keys. That key has no owner, no expiry and no second factor — copy it once and you have standing root until someone remembers to revoke it. AuthFI PAM removes the static key entirely. Authentication runs through identity first: AuthFI verifies the user, enforces MFA — TOTP or passkey on every SSH login, and only then grants access. No more shared keys.

  • The problem it removes: orphaned keys — credentials that outlive the employee because nobody ran grep across the fleet on their last day.
  • Bound to a person: the session carries alice@acme.com, not an anonymous key fingerprint, so the audit trail names a human.
  • The payoff: disable the user in AuthFI and they are locked out of every server instantly — one switch, whole fleet.
Terminal -- alice@prod-db-01
$ ssh prod-db-01.acme.authfi.io

AuthFI PAM | Authenticating alice@acme.com
MFA Required | Enter TOTP code: 847291
Verified    | MFA passed. Session started.

  User:    alice@acme.com
  Role:    devops
  Sudo:    enabled (via group: devops)
  Session: recording
  Expires: 2h from now

alice@prod-db-01:~$ sudo systemctl status postgres
* postgresql.service - PostgreSQL
   Active: active (running)

Every SSH login requires identity verification before a shell exists.

Shared SSH keys AuthFI PAM
Long-lived key in ~/.ssh/authorized_keys Short-lived certificate, expires in hours
Copy a key to every host, forever Trust one CA public key, once
Offboard = grep keys across the fleet Disable user → next cert is never issued
Who used this key? Unknown 1 identity bound to every session
Hosts trust one CA public key. Nothing per-user is ever copied to a server.

Credentials that expire

Short-lived, not standing. The credential dies before it can leak.

A standing key is a liability that compounds: every laptop it lands on, every backup, every ex-employee's home directory is a copy you can't see. AuthFI shrinks the blast radius by making the credential ephemeral — after a successful, MFA-verified login the session is scoped to a short window (the terminal above shows Expires: 2h), then re-authentication is required. A credential that expires in hours has almost no resale value if it leaks.

  • One trust root: hosts trust a single certificate authority instead of an ever-growing pile of per-user keys — the model OpenSSH's CA design (TrustedUserCAKeys) was built for.
  • Revocation is a non-event: you never chase keys across N machines — you stop minting them for that identity.
  • The payoff: the offboarding checklist shrinks to one line, and the auditor's "who could log in here?" has a single, current answer.

Authorization

Roles broker sudo. No one hand-edits sudoers again.

Authentication proves who; authorization decides what. AuthFI maps its roles to Linux primitives directly — AuthFI roles map to Linux groups and sudoers rules automatically. A user in the devops role lands in the matching Linux group, and the group's sudoers policy follows. The classic failure mode here is configuration drift: a hand-maintained /etc/sudoers that diverges per host until nobody can say who has root. Centralizing the role→group→sudo mapping removes that drift — privilege is derived from identity, not pasted onto a box.

  • Least privilege by default: on prod-db-01, devops gets sudo and dev gets read-only — the same role can be sudo on one host and unprivileged on the next.
  • Auto-provisioned accounts: a user created in AuthFI becomes a Linux account on next SSH — no useradd runbook, no pre-staging.
  • The payoff: grant or revoke elevation by editing one role, and every host honors it on the next login.
role → group → sudo
AuthFI role
devops
→
Linux group
devops
→
sudoers
(ALL) ALL
# derived from role membership, not hand-edited
%devops  ALL=(ALL) ALL
%dev     prod-db-01=(ALL) /usr/bin/less /var/log/*
Group membership follows the AuthFI role on every login. Drift, eliminated.

Accountability

Every command, captured. Every session, attributable.

Privileged access without a recording is an unanswerable incident review. AuthFI captures the session itself — every command logged, searchable, replayable, compliance-ready — and binds it to the identity that ran it, not a shared key. When an auditor asks "who touched the prod database, when, and exactly what did they type?", the answer is a query, not an archaeology project.

Session recording

Commands and output are captured per session and tied to the authenticated user. Searchable for "what happened" and replayable for "show me" — the evidence SOC 2 and PCI access reviews ask for.

Bound to a human

Because the credential is an identity and not a shared key, one identity maps to one session. There is no "the ops key did it" — the trail names alice@acme.com.

MFA on the record

The login itself is part of the trail: TOTP or passkey was presented before the shell opened, so the audit shows a verified human, not a process that found a key on disk.

Auth
SSH certificate (OpenSSH CA)
Cert TTL
2h, then re-auth
Trust root
One CA, no key copies
Audit
1 identity per session

Operate the fleet

Server inventory with access levels.

See all servers, who has access, and at what level — managed from the dashboard. Per host you see the OS, which role gets what, whether MFA is required, and whether the box is reachable right now.

console.authfi.io/pam/servers
ServerOSAccessMFAStatus
prod-db-01Ubuntu 22.04devops: sudo, dev: read-onlyRequiredOnline
prod-app-01Debian 12devops: sudo, dev: sudoRequiredOnline
staging-01Ubuntu 22.04dev: sudoOptionalOnline
ci-runner-01Amazon Linuxdevops: sudoRequiredOffline

Offline fallback

Networks partition; SSH can't wait for an IdP that's unreachable. Cached credentials cover network interruptions, and break-glass access keeps a documented, recorded path to a box when the control plane is down.

eBPF integration

Combine PAM with the AuthFI Agent to run SSH and HTTP policies on the same host. eBPF observes syscalls and connections in the kernel, so enforcement isn't bolted onto one protocol — it sees the workload itself.

Multi-OS support

Ubuntu, Debian, RHEL and Amazon Linux, shipped as native apt and yum packages — the same identity model whether the host is Debian-family or RHEL-family.

Enterprise PAM

Enterprise PAM features.

Identity-bound access, brokered privilege, captured sessions and lifecycle automation — one engine across the fleet, configured from the console.

MFA enforcement

TOTP or passkey on every SSH login. No exceptions.

Role-to-sudo mapping

AuthFI roles map to Linux groups and sudoers rules automatically.

Session recording

Every command logged. Searchable. Replayable. Compliance-ready.

Auto provisioning

User created in AuthFI -> Linux account created on next SSH.

Instant deprovision

Disable user -> locked out of every server instantly.

Offline fallback

Cached credentials for network interruptions. Break-glass access.

eBPF integration

Combine with Agent for SSH + HTTP policies on the same host.

Multi-OS support

Ubuntu, Debian, RHEL, Amazon Linux. apt and yum packages.

Get started

Ready to get started?

Free for 5,000 monthly active users. No credit card required.

Start free Read the docs