Workforce MFA · Linux & SSH MFA
Keycloak-backed MFA for SSH, sudo and Linux servers
We protect server access two ways: PAM modules that check a second factor against Keycloak for SSH and sudo, or short-lived SSH certificates issued only after a Keycloak login — so long-lived keys stop being the way in.
- PAM for SSH, sudo and console
- Short-lived SSH certificates
- No shared long-lived keys
Standards & integrations
- PAM
- RADIUS
- OpenSSH certificates
- OpenID Connect
- TOTP
Overview
Two ways to put Keycloak between people and servers
Linux authentication runs through PAM, and SSH can also trust certificates signed by a CA you control. With PAM, a RADIUS module asks Keycloak — through a RADIUS front end — to verify the second factor at SSH, sudo or console login. With certificates, engineers sign in to Keycloak, receive an SSH certificate valid for hours, and servers trust the CA instead of individual keys. Many teams use both: certificates for everyday access, PAM step-up for sudo.
What we deliver
- Server access design covering PAM and SSH certificates
- RADIUS front end for Keycloak, highly available
- SSH CA with OIDC login to Keycloak, where chosen
- PAM and sshd configuration as code
- Break-glass procedure for recovery access
- Rollout plan and key retirement checklist
Capabilities
What Linux & SSH MFA covers
Configured, tested and documented on upstream Keycloak — then handed over or operated by us.
PAM integration
A PAM RADIUS module sends the second factor to a RADIUS front end for Keycloak at SSH, console and other PAM-aware logins.
Step-up for sudo
Privilege escalation asks for a fresh one-time code, so a stolen session alone isn't enough to become root.
SSH certificates after Keycloak login
An SSH CA such as step-ca, with its OIDC provisioner pointed at Keycloak, issues short-lived certificates; OpenPubkey-based tools are another option.
Group-based access
Keycloak groups decide which servers and principals each engineer can use, so access follows role changes automatically.
Fleet rollout as code
PAM, sshd and CA trust are rolled out with Ansible or your configuration tooling, starting with bastions.
Audit trail
Authentications and certificate issuance are logged in Keycloak and the CA, ready to correlate with server logs in your SIEM.
Compatibility
Linux access scenarios
Which mechanism covers each kind of access. Distribution specifics are confirmed during the pilot.
| Platform | Integration | Notes |
|---|---|---|
| OpenSSH with keyboard-interactive | PAM + RADIUS → Keycloak | OTP prompt via RADIUS challenge; sshd configured for keyboard-interactive. |
| OpenSSH certificates | SSH CA with OIDC login to Keycloak | Certificates expire in hours; servers trust the CA, not individual keys. |
| sudo | PAM step-up | Fresh OTP on privilege escalation. |
| Console and local login | PAM | Keep an emergency path for recovery consoles. |
| RHEL, Ubuntu, Debian, SUSE | Same design | PAM file layout differs slightly per distribution. |
How it works
From first call to production
Choose PAM, certificates or both
We review how engineers reach servers today and pick PAM, SSH certificates or a mix for each environment.
Start with bastions
Jump hosts and a pilot group of servers are configured first, with break-glass access tested before enforcement.
Extend across the fleet
Configuration rolls out through your tooling, long-lived keys are retired, and automation accounts are handled separately.
Use cases
Where teams put it to work
Production server access
Require MFA or a fresh certificate for every engineer session on production systems.
Contractors and temporary access
Grant access that expires on its own through Keycloak groups and short certificate lifetimes.
Replacing shared keys
Retire shared or long-lived SSH keys that nobody can trace back to a person.
FAQ
Linux & SSH MFA questions, answered
Does Keycloak include a PAM module?
No. We use PAM modules that talk RADIUS to a RADIUS front end for Keycloak, or move SSH to certificates issued after a Keycloak login. Both keep Keycloak as the place where MFA policy lives.
Will automation and CI still work?
Yes. Service accounts and deploy keys are handled separately with their own restrictions, so MFA applies to people, not pipelines.
What if Keycloak is unreachable?
We keep a documented break-glass path — typically a sealed emergency account or a CA-signed emergency certificate procedure — and monitor its use.
Ready to roll out Linux & SSH MFA?
Walk us through your requirements on a free strategy call. We'll come back with an architecture, a delivery plan and a fixed scope.