0
Codes to type on a trusted elevation
Linux & Unix · Privileged access
sudo and su Multi Factor Authentication
Root is the prize in every Linux intrusion, and sudo and su are the doors to it. Spriv's PAM module puts a second factor on privilege escalation and validates it continuously in the background, so administrators aren't asked for a code every time they elevate.
sudo & su · Second factor without the prompt fatigue
0
PAM module for SSH, su and sudo
0+
Daily logins an admin can make without fatigue
0 ms
Typical time to clear the second factor
Why it matters
Why sudo and su need a second factor
Most intrusions start with an ordinary account. Privilege escalation is the step that turns a contained incident into a full compromise.
A compromised account becomes root
An attacker who has a user's password, or a session they hijacked, can run sudo with that same password. A second factor on the phone means the password alone no longer grants root.
Shared and reused passwords
The root password used with su is often known to several people and rarely rotated. Tying elevation to each person's paired phone makes it personal again.
Auditors ask for it
Strong authentication for administrative access is part of PCI DSS, FFIEC, HIPAA and SOX expectations. Spriv verifies out-of-band and transfers no personally identifiable information.
How it works
Continuous MFA for privilege escalation
The common approach to sudo 2FA asks for a six-digit code on every elevation. Spriv authenticates once, then keeps validating in the background.
STEP 01
Authenticate once
The first time a user signs in from a workstation, they approve it on their paired phone. Spriv records that workstation-and-phone pair.
STEP 02
Elevate without interruption
Later sudo and su requests from the same pair are validated in the background through PAM. No code, no tap, no broken flow.
STEP 03
Challenge on anything unusual
A different workstation or a phone that isn't where it should be triggers a challenge before elevation is granted.
Fewer prompts, more attention. Admins who are prompted on every sudo learn to approve without reading. Keeping routine elevations silent means the rare prompt gets noticed. Why seamless MFA works for admins.
Compared
Code-per-command 2FA vs Spriv for sudo
Typical TOTP on sudo
Every elevation stops for the user to unlock their phone, open an authenticator and type six digits within the time window. Secure, but it is quickly turned off on busy servers.
Spriv adaptive on sudo
Routine elevations clear in the background on the trusted pair. TOTP is still there as an offline fallback, and push approval is available for high-risk moments.
Questions
sudo and su MFA questions
Does Spriv replace the sudoers file?
No. sudoers still decides who is allowed to elevate and what they may run. Spriv confirms that the person elevating really is that user.
How is sudo and su MFA installed?
With the same PAM module that protects SSH. Install it once, then add it to the PAM configuration for each service you want to protect. Stacking differs between distributions. PAM install guide.
How do I avoid locking myself out of root?
Keep a root session open while you change the PAM configuration and test from a second session. Also keep two administrator accounts paired with different phones, plus your saved Recovery Code.
What if the server or phone is offline?
TOTP codes are generated on the phone and need no internet or carrier signal, so they work as the fallback.
Explore
Related pages
Checkit!
Guard root without slowing your admins
Two free users and two free servers, no credit card. One PAM module protects SSH, su and sudo.