Two-factor authentication (2FA)

Why it matters for servers

A password or an SSH key on its own can be guessed, phished or copied. A second factor means that one stolen secret is not enough. CISA states that users who enable MFA are significantly less likely to get hacked, and that any MFA is better than none, while phishing-resistant methods such as FIDO/WebAuthn are the standard to aim for.

Second factors for SSH

For SSH the practical options are a FIDO2 hardware-backed key (ed25519-sk) and a time-based one-time code through PAM. Both, and a safe rollout that avoids locking you out, are covered in our SSH two-factor authentication guide.

Which logins around a server need a second factor

CISA's multifactor authentication page groups factors into three kinds: something you know (a PIN or password), something you have (an authentication app or a phone) and something you are (a fingerprint or face scan). A real second factor comes from a different kind than the first, so a password followed by another memorised secret is still one kind. For organisations, CISA names remote access, email and billing systems as priorities, and that maps well to a VPS.

• SSH logins for administrators. Attackers probe this door constantly, and the SSH two-factor authentication guide covers how to add the factor.
• Your hosting account. A provider panel with a web console, rescue mode or a password reset is a separate way in that your sshd settings do not control. Protect it with a second factor too.
• Your email account. Password resets for the provider and for the domain usually arrive there, so whoever controls the mailbox can often take over everything else.
• Billing and DNS accounts. Losing them can mean losing the server or the domain without anyone touching SSH.

Secure these in that order of exposure, and choose a FIDO hardware key where the provider offers one, since CISA calls FIDO/WebAuthn the only widely available phishing-resistant method.

Check that it really works and plan for the bad day

Turning on a second factor is only half the job. Verify it, then prepare the recovery before you need it. On the server, confirm which methods are actually required:

sudo sshd -T | grep -iE '^(authenticationmethods|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication) '

The sshd_config manual says AuthenticationMethods lists the combinations a user must complete, and that the value any restores the default of accepting a single method. If the output still says any, no second factor is enforced, whatever the rest of your setup suggests. Then test from a brand-new connection with the key alone and confirm it is not enough.

Plan recovery in advance:

1. Register a spare hardware key or keep the one-time scratch codes offline, stored apart from the laptop.
2. Know how to reach your provider's console, and keep that account's second factor available too.
3. Write down how a new administrator is enrolled and how a leaver is removed.
4. Give automation its own restricted keys, because a deploy job cannot answer a prompt, and never share a person's hardware key.

Review the list of enrolled people on a schedule, the same way you review authorized_keys.

Related terms: Key-based authentication, SSH, sshd_config, Fail2ban, TOTP, FIDO2 and WebAuthn, PAM.