iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
SSH keys and two-factor authentication are complementary, not competing choices. A normal SSH key is one cryptographic factor: your client proves possession of a private key whose matching public key is listed in the account’s ~/.ssh/authorized_keys. Two-factor authentication (2FA) adds a second, independent factor such as a FIDO2/U2F security key or a time-based one-time password (TOTP).
For most Ubuntu VPS deployments, the sound sequence is to create an Ed25519 key protected by a passphrase, verify a non-root login in a second session, then disable password authentication and direct root login. Add FIDO/U2F when your team can keep a spare token and maintain console-based recovery. The sections below show what each control protects, how to combine them, and how to avoid locking yourself out.
For a self-managed Linux VPS with full root access, NVMe storage, and L3/L4 DDoS protection in the USA East, Netherlands, or Ukraine, see Antihost VPS.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesWhat an SSH key actually proves
SSH public-key authentication uses an asymmetric key pair. The server stores the public key; the private key remains on your workstation, automation runner, or hardware token. During login, the client signs session data with the private key and the server verifies that signature with the stored public key. The private key is never sent to the VPS.
#1 Best Overall
- POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
Ubuntu Server documentation describes this as authentication “without the need of a password, using cryptographic keys.” That removes password guessing and credential-stuffing from the SSH login path, provided the private key is protected and the server accepts no weaker fallback.
A passphrase is protection for the key file
A passphrase encrypts the private-key file at rest. It does not create a second authentication factor for an SSH session: the passphrase unlocks the key on the same device that holds it. If an attacker steals an already-unlocked key from a running workstation, the passphrase may not help. Use an agent with a limited lifetime, screen lock, full-disk encryption, and endpoint security in addition to the SSH passphrase.
One key can represent one person or one workload
Give each administrator and automation system its own key pair. Shared private keys make attribution and revocation difficult. A separate key lets you remove one person’s access by deleting only that person’s public-key line from authorized_keys, without interrupting other users.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Why two-factor authentication is a separate layer
2FA requires two different categories of evidence. In an SSH deployment, the first factor is usually the public-key signature. The second can be a physical FIDO/U2F device that must be present and touched, or an OTP generated by an authenticator application.
Ubuntu’s guidance says an extra layer can be added “to the default key-based authentication using two factor authentication.” The distinction matters operationally: a stolen ordinary private key may be enough for an attacker when no second factor is required, while a stolen FIDO-backed credential still requires the registered hardware device.
Are SSH keys considered 2FA?
No. A standard software-backed SSH key is one factor, even when it has a strong passphrase. It becomes part of a two-factor login only when the server also requires an independent factor, for example a FIDO/U2F assertion or a PAM-managed OTP.
Rank #2
- POWERFUL SECURITY KEY: The YubiKey 5C NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5C NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5C NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
Do you need 2FA if you use SSH keys?
Not every VPS needs the same control. A single-user, low-impact server with tightly protected keys, disabled password authentication, restricted network access, and reliable console recovery may be acceptable with key-only SSH. Add 2FA when administrative access is valuable, several people connect, devices are mobile or unmanaged, or phishing and key theft are realistic concerns. Automation often needs a non-interactive key-only path, so apply 2FA to human administrator accounts while isolating machine accounts and constraining their commands.
SSH keys versus 2FA by security and operating concern
| Concern | SSH key only | SSH key plus FIDO/U2F | SSH key plus PAM OTP |
|---|---|---|---|
| Brute-force resistance | Very strong when password authentication is disabled; the attacker must obtain a valid private key. | Very strong; a valid key and the registered hardware device are required. | Strong; a valid key and a current OTP are required. |
| If a private key is stolen | The thief may log in until the public key is revoked or other controls stop the attempt. | The thief still needs the enrolled FIDO/U2F device and its user-presence action. | The thief still needs the user’s OTP generator or seed, unless the second factor has also been compromised. |
| Phishing resistance | Good against password phishing, but malware can target the private key or agent. | Strong phishing resistance because the hardware signs for the intended SSH origin. | Better than a password, but a real-time phishing relay can sometimes capture and forward an OTP. |
| Unattended automation | Well suited to CI jobs and scheduled tasks when keys are scoped and rotated. | Usually unsuitable for unattended jobs because the device must be connected and present. | Awkward for unattended jobs because a human or an OTP broker must supply codes. |
| Recovery complexity | Low if you keep a second administrator key and provider console access. | Higher; you need spare tokens, enrollment records, and a lost-token procedure. | Higher; you need a documented way to reset or replace the PAM OTP secret. |
| Hardware and support cost | No dedicated authentication hardware is required. | Requires one or more FIDO2/U2F security keys and a way to store spares. | Requires an OTP application or token and PAM configuration that matches the installed OpenSSH release. |
These are qualitative properties, not a common benchmark or a percentage comparison. The right combination depends on the value of the VPS, the number of operators, and whether access must be automated.
Build a secure key-only baseline on Ubuntu
Perform the changes in an existing session and keep that session open until a new login has succeeded. A provider console or serial console should be available before you alter SSH settings.
1. Plan identities and recovery first
- Create a named, non-root account for each human administrator.
- Decide where each private key will live and who can access it.
- Prepare a second administrator key or a break-glass account stored securely.
- Confirm provider console, rescue mode, or equivalent out-of-band access.
- Record which public key belongs to which person or service so revocation is unambiguous.
2. Generate an Ed25519 key
Ubuntu recommends Ed25519 as its general-purpose key algorithm. On the client, run:
ssh-keygen -t ed25519Accept a protected file location or provide one explicitly when several identities are in use. Enter a long, unique passphrase. Keep the private file private; the file ending in .pub is the value that can be installed on the server.
RSA 4096 remains an alternative for environments that require it. Generate it explicitly with:
Rank #3
- POWERFUL SECURITY KEY: The YubiKey 5 NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5 NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5 NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
ssh-keygen -t rsa -b 4096Do not copy private-key text into tickets, chat, cloud-init logs, or shell history.
3. Install the public key for the non-root account
Place the public key on the server user’s ~/.ssh/authorized_keys. The directory should be owned by that user and not writable by other users. If you use a provider’s key-injection feature, verify that it placed the key in the intended account rather than only in the initial provisioning account.
After installation, connect by naming the key and user:
ssh -i ~/.ssh/id_ed25519 admin@server.exampleUse your actual hostname or address; the example does not imply a particular provider.
4. Test a second session before changing sshd
- Leave the original SSH window connected.
- Open a new terminal and log in with the new non-root account and key.
- Run a harmless command such as
idand confirm the expected username and groups. - Confirm that you can elevate with your normal, audited administrative method if required.
- Only after this succeeds should you edit the SSH daemon configuration.
This second-session test catches wrong permissions, an incorrect username, an unoffered key, and agent problems while your first session is still a rescue path.
5. Disable password authentication and direct root login
DigitalOcean’s Ubuntu hardening guidance identifies disabling password authentication and direct root login as the two most important steps after successful key login. In the effective sshd configuration, set:
Rank #4
- POWERFUL SECURITY KEY: The Security Key NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key NFC via USB-A and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yesSome images include drop-in files under /etc/ssh/sshd_config.d/; a later drop-in can override the main file. Inspect the effective settings with your installed OpenSSH tools, validate syntax, and reload rather than abruptly terminating the daemon. Then repeat the second-session test. Keep the console route available because a typo or cloud-init override can still block SSH.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Add FIDO2/U2F hardware authentication
OpenSSH 8.2 added support for U2F/FIDO hardware authentication devices. A security key keeps the private credential in tamper-resistant hardware and requires the device to be present, normally with a touch, for each authentication.
Use a security-key-backed credential
On a client with a compatible OpenSSH version and a connected FIDO device, create a security-key-backed credential with an -sk algorithm, for example:
ssh-keygen -t ed25519-skFollow the prompts to set a device PIN if supported and touch the key when requested. The resulting public key is installed in authorized_keys like any other SSH public key. Test the login while the token is connected before removing an older key.
Design the token lifecycle
- Enroll a spare token before enforcing hardware-only access.
- Store the spare in a controlled, documented location separate from the primary token.
- Record the token owner and the servers or accounts where its public key is authorized.
- Revoke the public key immediately when a token is lost, transferred, or suspected compromised.
- Keep console recovery available for the moment a token is unavailable.
A FIDO key improves phishing resistance, but it does not replace account separation, patching, least privilege, or network controls. It also creates a physical dependency: an unattended job cannot normally complete an interactive token touch.
Free tools Windows power users keep installed
One-click scans. No signup required.
Require a PAM OTP after the SSH key
If hardware tokens are impractical, Ubuntu can combine public-key authentication with a PAM-backed OTP. The exact package, enrollment flow, configuration-file locations, and defaults vary by Ubuntu release and PAM stack, so verify the syntax against the OpenSSH version installed on your VPS.
Best Value
- The information below is per-pack only
- POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
Use an explicit authentication chain
The relevant sshd directives are:
PubkeyAuthentication yes
KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive:pamThe comma in AuthenticationMethods means the public key must succeed before the interactive PAM OTP step is offered. Without that chain, enabling keyboard-interactive authentication alone can accidentally permit an OTP-only or otherwise weaker path, depending on the PAM stack.
Roll out OTP without locking out administrators
- Enroll one administrator’s OTP secret while a tested key session remains open.
- Test a fresh login and verify that the key is requested first and the OTP second.
- Enroll the remaining administrators and a documented break-glass account.
- Test token replacement or secret reset through the provider console.
- Only then remove password-based or temporary fallback methods.
Keep an out-of-band recovery path. A malformed PAM rule can prevent every SSH login even when the key itself is valid.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Automation, service accounts, and least privilege
2FA is designed primarily for human authentication. Build automation around dedicated key pairs with narrow permissions rather than sharing an administrator’s private key. Restrict service accounts to the commands, directories, and hosts they need; where appropriate, use forced commands, source-address restrictions, and separate deployment users.
Protect automation keys in a secrets manager or an isolated runner, rotate them on a schedule appropriate to the workload, and revoke them immediately when a runner is retired. Do not place a human’s FIDO credential in a build pipeline simply to satisfy a policy designed for interactive access.
What to do if a key or security token is lost
Lost or stolen ordinary private key
- Assume the key may be usable if its passphrase was weak, exposed, or absent.
- Log in with another administrator key or the provider console.
- Remove the corresponding public-key line from every affected
authorized_keysfile. - Review logs for unexpected source addresses, users, commands, and persistence.
- Generate a replacement key, install it, and test it before ending the recovery session.
Lost FIDO/U2F token
Use the spare enrolled token or console access, remove the lost token’s public key, and enroll a replacement. If no spare exists, the provider console is the recovery route; this is why a spare-token policy is part of the security design, not an optional convenience.
Lost access to every key and token
Use the VPS provider’s console, rescue environment, or recovery workflow. Restore access by adding a new public key to the intended account, correcting ownership and permissions, and validating sshd configuration before restarting or reloading it. If the provider offers no out-of-band path, treat that limitation as a deployment risk and select a service that does.
Common failure modes and fixes
“Permission denied (publickey)”
- Confirm you are using the correct username; root and the provisioned user may have different key files.
- Run the client in verbose mode to see whether the intended identity is offered.
- Check ownership and permissions of the home directory,
.ssh, andauthorized_keys. - Verify the public key line was not wrapped or altered when copied.
- Check whether an sshd drop-in overrides
PubkeyAuthenticationor points to a different authorized-keys file.
The key works, but OTP is never requested
Check that AuthenticationMethods publickey,keyboard-interactive:pam, KbdInteractiveAuthentication yes, and UsePAM yes are active in the effective configuration. Confirm that the PAM module is installed and referenced for the SSH service. Test in a new session while preserving the working one.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Disabling passwords caused a lockout
Use the provider console, restore a known-good configuration temporarily, and reload sshd after syntax validation. Do not close the only working shell until a new key login has succeeded. Once recovered, correct the key path, account, or drop-in override and repeat the staged test.
Quick Recap
A practical decision framework
Choose key-only SSH when
- You can protect private keys with passphrases, device controls, and short-lived agents.
- Password authentication is disabled and direct root login is disabled.
- Each person and workload has a separate key.
- You maintain a second administrator key and tested console recovery.
Add FIDO/U2F when
- The VPS holds sensitive data or production control.
- Phishing resistance and protection from a copied software key justify a physical token.
- Every administrator can keep a primary and spare token available.
- You can document enrollment, revocation, and console recovery.
Use PAM OTP when
- Your environment already operates a managed OTP system.
- Hardware-token procurement or handling is impractical.
- You can validate the PAM stack for the exact Ubuntu and OpenSSH versions installed.
- You accept the additional recovery and reset procedures.
Operational checklist
- Generate Ed25519 keys with
ssh-keygen -t ed25519; use RSA 4096 only where compatibility requires it. - Protect every private key with a strong passphrase and secure endpoint storage.
- Install public keys only for named users or constrained service accounts.
- Test a non-root key login in a second session.
- Disable password authentication and direct root login after that test.
- Use FIDO/U2F or PAM OTP as a second factor for human administrators when the risk warrants it.
- Keep a spare hardware token, a spare administrator key, and provider console access.
- Document how to revoke lost credentials and how to restore access without SSH.
- Review SSH logs and rotate or revoke credentials when staff, devices, or runners change.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
