SSH two-factor authentication adds a second check to SSH sign-in, but it protects only the SSH path you configure. On Ubuntu Server, the documented PAM-backed approach uses a public key first and a one-time code second; establish working key access and recovery before requiring that code.
The steps below focus on Ubuntu’s current TOTP/HOTP instructions. PAM stacks and SSH settings vary between distributions and releases, so do not apply Ubuntu configuration unchanged elsewhere. SSH MFA is one layer alongside account, firewall, update and provider-console security.
Confirm your distribution and current SSH access
Start by identifying the operating system and release, and confirm that you can sign in over SSH now. On Ubuntu, lsb_release -a or the release information in /etc/os-release can help identify the system. Check the current Ubuntu Server documentation for the release you run before changing authentication; directive names and PAM arrangements have changed over time.
Confirm that you have a separate sudo-capable account, not just a root login whose access you are about to alter. Keep an existing privileged SSH session open while you make changes. If a new configuration fails, the open session may let you inspect the problem without depending on a fresh login. It is not a substitute for an out-of-band recovery path.
Know how to reach your VPS provider’s web console or equivalent recovery facility before you proceed. This is distinct from SSH: the console is an administrative route provided by the host, and its availability and authentication rules depend on that provider. MFA for your provider account does not automatically require a second factor for SSH into the guest operating system, and SSH settings do not secure the provider account.
MFA for SSH also does not automatically apply to applications, databases, file transfer services, or every other account on the VPS. If you separately decide to require an additional factor for sudo, treat that as a different change and plan its own testing and recovery. Keep the scope of this procedure clear: it changes how SSH users authenticate.
Set up key access and recovery first
Before introducing OTP, make sure every intended SSH user can authenticate with a public key. Test a new key-based login in a separate terminal while the existing session remains open. A key that exists on one administrator’s account does not help another user who has not installed and tested their own key.
Ubuntu’s procedure expects the public key to authenticate first. Password authentication is disabled in its example, so users who have not prepared a key may be unable to get through the first step once the policy is enforced. Make an inventory of the people and automated processes that need SSH access, and confirm their intended keys work before changing the daemon policy.
Recovery needs to cover more than a lost phone. Decide who can reach the provider console, how that person will authenticate there, and how they will repair SSH configuration or a user’s second-factor enrollment if needed. Check that the console path is usable before relying on it. The provider’s recovery design may differ, so consult its own documentation rather than assuming every VPS offers the same controls.
Treat emergency codes and OTP secrets as credentials. Store recovery material somewhere protected and accessible to an authorised administrator if the primary device is unavailable. Avoid leaving a copy in a shell history, an unprotected shared folder, or a note that is itself accessible through the account being protected. Recovery material can restore access, but it can also weaken the protection if exposed.
If this VPS also runs a continuous broadcast, separate reliable operation from safe administration. A stream should not require you to leave a privileged shell session open; see how to keep a YouTube livestream running after closing an SSH session. That separation makes it easier to preserve an administration session for testing without treating it as part of the stream’s runtime.
Choose the documented second-factor method
Ubuntu documents a PAM-based TOTP/HOTP route using the libpam-google-authenticator package and a per-user enrollment command. The user scans a QR code or enters a generated secret into a compatible authenticator application. In the intended SSH flow, the public key is the first method and the code arrives through PAM’s keyboard-interactive prompt as the second.
TOTP is usually the simpler choice when the authenticator supports it. It derives the valid code from time, which means the device and server need sufficiently aligned clocks. If a code is rejected, check time synchronisation on both sides before changing SSH settings. HOTP advances through a sequence of codes; generating codes that the server does not consume can desynchronise client and server, potentially requiring recovery out of band.
The per-user enrollment data includes a shared secret and emergency passcodes. The secret must remain confidential: someone who obtains it may be able to generate valid codes. Follow the current module prompts and Ubuntu guidance for the release in use rather than assuming that an older tutorial’s prompts or defaults still apply.
Ubuntu recommends U2F/FIDO hardware authentication devices for stronger two-factor security where practical, and documents OpenSSH hardware-backed security-key types such as ecdsa-sk and ed25519-sk. That is a different configuration route, with client, server and hardware requirements of its own. Do not casually combine it with PAM TOTP/HOTP: Ubuntu’s TOTP guide says the simultaneous arrangement is not recommended there because it has not been tested in that guide. Choose one understood route and test it.
The central Ubuntu reference is the Ubuntu Server guide to two-factor authentication with TOTP/HOTP. If you are on another distribution, use that vendor’s current instructions for its SSH and PAM packaging instead of copying Ubuntu’s PAM edits.
Configure PAM for the target system
For Ubuntu, follow the current Server guide’s installation and enrollment procedure. It documents installing the PAM module with sudo apt update && sudo apt install libpam-google-authenticator, then setting up each SSH user’s OTP secret. Enrol every user who will be required to use the second factor before enforcement, and keep the emergency codes in the recovery arrangement you prepared.
PAM is the part of the authentication path that invokes the OTP module. Ubuntu’s documented procedure includes a change to /etc/pam.d/sshd; use the exact line and placement specified by the current instructions for your release. Do not replace the whole file with a generic example: other PAM entries and included stacks may be necessary for your system’s authentication policy.
Inspect the PAM file and any included files to understand what SSH can accept. Keyboard-interactive is a prompt mechanism, not a synonym for OTP: it can also reach password-related PAM modules. Mozilla’s OpenSSH server guidance warns that PasswordAuthentication no alone does not prove that password authentication is impossible when PAM remains available through keyboard-interactive. Make sure the PAM route has the factors you intend and no unintended password fallback.
That caution matters especially when adapting instructions from a different release. Ubuntu’s older tutorial and current Server documentation use different settings in places. Prefer the current Server page for the Ubuntu release you run, and reconcile existing configuration rather than layering duplicate or contradictory directives on top of it.
Apply the SSH authentication policy
Ubuntu’s current example uses these SSH daemon settings to require a public key followed by keyboard-interactive authentication, while disabling SSH password authentication:
KbdInteractiveAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey,keyboard-interactive
Use this excerpt as a guide to the intended flow, not as a universal drop-in block. Ubuntu 20.04 LTS and earlier use ChallengeResponseAuthentication yes in place of KbdInteractiveAuthentication yes in the Ubuntu instructions. Other distributions or releases may use different names, defaults, or PAM arrangements.
Before editing, inspect the effective SSH configuration, including files brought in through Include directives. A setting can already appear elsewhere, and duplicate entries can be misleading because OpenSSH configuration handling depends on context and ordering. Edit the intended source, then follow the release-specific validation and service reload or restart steps in the vendor documentation.
Do not interpret the three lines in isolation. AuthenticationMethods publickey,keyboard-interactive describes the sequence, while PAM determines what the interactive prompt actually accepts. If PAM still offers a password route, the combination may not enforce the key-plus-OTP policy you thought it did. Validate the result through an actual fresh login rather than treating a successful configuration parse as proof of the required factors.
For a VPS used to operate a 24/7 channel, SSH is also an operational maintenance route, not the broadcast itself. A second-factor change should not be rushed during an unattended maintenance window. If your workflow is based on an uploaded video rather than a process you manage from a shell, how pre-recorded video streaming can work without keeping a PC on explains a separate operating choice; it does not remove the need to secure VPS accounts you still administer.
Test a second session before enforcing
Keep the original privileged session open, then start a completely new SSH connection from another terminal or client. Confirm that it asks for the expected key and OTP sequence, and that the code is accepted. A test performed only in an already authenticated session does not show that a new sign-in can complete the new policy.
Test with each intended account, not only the account that made the configuration change. Confirm that users without the correct key cannot fall through to password authentication, and that properly enrolled users can complete the second factor. Never deliberately test by closing the only working session before a new one succeeds.
If login fails, use the preserved session to inspect the daemon configuration and PAM path, or use the provider console if necessary. Check for a wrong directive for the release, an un-enrolled user, a key issue, a time mismatch for TOTP, or a PAM module path that differs from the documented Ubuntu setup. Correct one cause at a time and test again.
Once a fresh login has completed the full intended flow, only then close the original session. If you changed the SSH daemon configuration, follow the relevant documentation to reload or restart it safely; do not assume that every service manager or distribution uses the same command. A configuration check and successful new session together provide better evidence than either alone.
Review recovery and the wider account security
Revisit the recovery plan after MFA works. A phone can be lost, damaged, replaced or unavailable, and an authenticator may not transfer secrets automatically. Verify that an authorised person can reach stored emergency codes and the provider console without weakening the everyday login policy. The recovery route should be available when needed but protected from routine account compromise.
Check that provider-account MFA is enabled where the provider supports it, since console access is separate from SSH. Keep the VPS and packages maintained, limit who has administrator access, use an appropriate firewall policy, and remove stale accounts or keys. These controls address different risks; a second factor cannot make an unpatched service safe or compensate for a broadly shared administrator credential.
Review enrolled users when roles change. Remove access for users who no longer administer the machine, rotate or revoke keys when their exposure warrants it, and update OTP enrollment through the documented process if a device is replaced. Make changes in a way that preserves a tested administrator path rather than disabling an account before confirming another can take over.
For a channel operator, operational monitoring is also separate from access control. Knowing whether a stream has stopped does not secure SSH, and MFA does not tell you whether the broadcast is healthy. A practical guide to monitoring a 24/7 study stream automatically addresses continuity monitoring as a distinct job. Likewise, if your Linux workflow uses a local media process, setting up a continuous Hindi bhajan stream with OBS concerns the stream process rather than VPS login security.
The useful outcome is a narrower, tested SSH entry path: each user has a working key, the intended second factor is enrolled, PAM does not provide an accidental fallback, and someone can recover access if a device fails. Keep checking the relevant Ubuntu or distribution documentation when the operating system or authentication stack changes.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does SSH two-factor authentication secure the whole VPS?
No. The procedure described here adds a second authentication step to the SSH login path you configure. It does not automatically protect applications, databases, provider-console access, or other accounts, so combine it with appropriate account, update and network controls.
Can I use these Ubuntu instructions on any Linux distribution?
No. PAM stacks, package names and SSH directives vary by distribution and release. Use the current documentation for your system; even Ubuntu 20.04 LTS and earlier use a legacy directive name in the documented configuration.
Why keep a session open while testing?
An open privileged session gives you a way to inspect or correct a failed change while a fresh connection tests the full key-plus-code flow. It is not a recovery plan by itself, so confirm access to your provider’s console or equivalent route before changing SSH authentication.
Is TOTP or HOTP preferable?
Ubuntu generally prefers TOTP when the authenticator supports it, because HOTP can desynchronise if generated codes are not accepted. TOTP depends on sufficiently aligned clocks, so correct time on the device and server matters.