Advertisement
Once key-only SSH is set up, the next suggestion is usually two-factor authentication: requiring a TOTP code from an authenticator app on top of the private key. It's presented as the obvious next step. More factors mean more security. That's true, but we need to be specific about the exact threat this addresses. Because that determines where the extra friction is worth it, and where it isn't.
What it actually protects against
Key-only SSH already ensures that a guessed, leaked, or phished password won't get anyone in. There is no password to steal. SSH 2FA specifically protects against the private key itself being compromised: stolen from a laptop, copied from an unencrypted backup, or lifted from an otherwise compromised machine. If that happens, the key alone isn't enough; the attacker also needs the TOTP code sitting on your phone.
Laptops get stolen. Backups get misconfigured. "The key is on an encrypted disk" only works if the disk was actually encrypted and the laptop was locked. It's a real scenario. But it is a very specific scenario, not a general "SSH security" fix. Key-only auth already handles the general threat model exceptionally well.
The setup
pam_google_authenticator is the standard way to add TOTP to SSH on Linux:
apt install libpam-google-authenticator
google-authenticator
This generates a secret (and a QR code) along with backup codes. Next, you tell PAM and SSH to require it:
# /etc/pam.d/sshd
auth required pam_google_authenticator.so
# /etc/ssh/sshd_config
AuthenticationMethods publickey,keyboard-interactive
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive is the critical line. It requires both the key and the TOTP prompt. If you get this wrong (like leaving it unset), the server might accept either factor alone, completely defeating the purpose. Always test this in a second terminal before closing your current session.
Where it breaks things
The friction hits in two places. First, human logins. Every interactive SSH session now needs your phone. It's annoying if you log in dozens of times a day, but manageable.
Second—and much more critically—it breaks automation. A CI/CD pipeline deploying via SSH, an Ansible playbook, or a cron job rsyncing to a remote host: none of these have a human sitting there to type a 6-digit code. Applying AuthenticationMethods publickey,keyboard-interactive server-wide instantly breaks all of these. You usually won't notice until the next scheduled job quietly fails.
The middle ground
Instead of blanket 2FA everywhere, apply it only to interactive human logins. Let automation use separate, restricted service accounts that bypass the 2FA requirement. Those accounts should be restricted in other ways anyway, like a forced command in authorized_keys, or scoping the key so it can only run a specific script.
# /etc/ssh/sshd_config
Match User deploy,admin
AuthenticationMethods publickey,keyboard-interactive
Match User ci-deploy
AuthenticationMethods publickey
This way, human accounts running arbitrary commands get the extra security factor. The narrowly-scoped automation accounts—which couldn't provide a TOTP code anyway, and whose keys live in CI secrets rather than on a human's laptop—keep working without friction.
My verdict
If a server is only ever accessed by automation and has no human interactive logins, SSH 2FA doesn't add much. The threat model (a stolen human-held key) doesn't apply.
For servers where humans actually log in and run commands—especially production environments with real data—the laptop-theft scenario is real. The small friction of a TOTP prompt is absolutely worth it, provided you scope it properly with Match User so you don't quietly break the automation keeping the lights on.
Advertisement