Set AuthenticationMethods publickey,password in the effective OpenSSH server configuration. This makes a user complete public-key authentication first and password authentication second; either factor alone is insufficient. Keep PubkeyAuthentication yes and PasswordAuthentication yes (or the equivalent methods used by your PAM setup) enabled, validate the complete configuration, reload SSH, and test a new session before closing your existing administrative connection.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
The setting that enforces both factors
OpenSSH uses the AuthenticationMethods directive to define which authentication methods must succeed before a login is accepted. For a key-plus-password login, use:
As an Amazon Associate I earn from qualifying purchases.
AuthenticationMethods publickey,passwordThe comma is significant. It creates one sequence in which every listed method must succeed. OpenSSH offers only the next method in that sequence, so the client must prove possession of an authorized private key before the server offers the password step. A password cannot be used first to bypass the key requirement.
Whitespace has a different meaning. Separate, whitespace-delimited lists are alternatives: completing any one complete list can be sufficient. Do not replace the comma with a space when your goal is to require both methods.
#1 Best Overall
What must be enabled elsewhere
AuthenticationMethods does not turn authentication mechanisms on by itself. Every method named in the sequence must also be enabled in the effective sshd configuration. For this policy, the relevant settings commonly include:
PubkeyAuthentication yes
PasswordAuthentication yes
AuthenticationMethods publickey,passwordThe exact defaults, file names, and include layout vary by Linux distribution and OpenSSH packaging. A setting in the main file can be changed or overridden by an included snippet, and a Match block can give a particular user or group different behavior. Inspect the complete effective configuration rather than assuming that the first value you see is the one the daemon uses.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Password authentication may be backed directly by the account password or by the distribution’s configured PAM stack. The prompt and the policy applied after the key step therefore depend on which authentication method is enabled and how the operating system is configured.
Apply the policy without locking yourself out
A configuration error can prevent every new SSH session, including an administrator’s. Use this rollout procedure:
Rank #2
- Keep a working administrative session open. Do not use the session you are editing as your only recovery path. If the machine has a local console or out-of-band console, confirm that it is available before changing authentication.
- Confirm that the account has a usable public key. The public key must already be authorized for that account, and the matching private key must be available to the person logging in. A password by itself will no longer be enough once the policy is active.
- Edit the effective server configuration. Add
AuthenticationMethods publickey,passwordin the global section or in the appropriate user/group-specificMatchblock. Ensure that public-key and password authentication remain enabled for the same scope. - Check all included snippets and scope rules. Distribution packages often include additional configuration files. Review those files and any
Matchsections so an override does not silently disable one of the required methods or apply the rule to the wrong accounts. - Run the distribution’s SSH syntax or configuration test. Use the command documented for your Linux distribution and correct every reported error before reloading the daemon. A syntax check catches malformed directives; it does not prove that a particular user’s key is authorized or that the PAM password path works.
- Reload the SSH service using the distribution’s documented service command. A reload asks the running daemon to read the corrected configuration while preserving existing sessions. Follow your distribution’s service name and procedure rather than assuming that every system uses the same unit name.
- Open a separate, new SSH session. Leave the original session untouched while testing. The new connection should first ask the client to perform public-key authentication and then present a password prompt.
- Close the old session only after the new login succeeds. If the test fails, use the still-open session or console to inspect the effective configuration and restore the previous working policy.
What a successful login looks like
The sequence is deliberate:
- The client offers a public key that the server accepts for the target account.
- The server advances to the next method in the configured list.
- The client receives a password request and submits the account password through the enabled password or PAM path.
- Access is granted only after both steps succeed.
If the key is rejected, OpenSSH does not skip ahead to the password step. If the password is wrong, possession of the private key alone does not complete the login. This ordering is the main distinction between a true sequential requirement and a configuration that merely permits two independent login methods.
Software keys and hardware-backed FIDO keys
Normal OpenSSH key pairs
A standard OpenSSH public/private key pair satisfies the public-key part of the sequence. The public half is placed in the account’s authorized-key configuration; the private half stays with the user or the system that initiates the connection. The server never needs the private key, and the password remains a separate factor.
Protect the private key with the controls appropriate to your environment. A copied private key can satisfy the first step unless it is separately protected, so requiring a password does not make an exposed private key harmless. The combined policy is strongest when the private key is itself protected and the account password is managed securely.
FIDO-backed OpenSSH keys
Current OpenSSH documentation lists FIDO authenticator algorithms including ecdsa-sk and ed25519-sk. A compatible hardware security key can therefore supply the public-key step while keeping key operations tied to a physical authenticator. The password requirement remains unchanged: the user still has to complete the password method after the hardware-backed key succeeds.
Hardware-backed keys are optional. Ordinary software-generated OpenSSH keys meet the configuration requirement, while FIDO keys add a different operational dependency: the authenticator must be present and usable at login time. Plan a recovery path before making a hardware token the only authorized key.
Choose the policy scope deliberately
| Scope or choice | Effect | When it fits | Operational concern |
|---|---|---|---|
Global AuthenticationMethods publickey,password |
Applies the sequence to accounts covered by the global configuration. | Uniform policy for a controlled fleet or all SSH users. | A mistake affects every account, including emergency administrators. |
Match-scoped policy |
Applies the sequence only to the users, groups, addresses, or other conditions defined by that block. | Gradual rollout or different requirements for separate administrative populations. | Ordering and scope rules can make the effective value differ from the global line; verify the account you are testing. |
| Software public/private key | Uses a conventional OpenSSH key pair for the first method. | Most deployments and automated administration. | The private key must remain available and protected. |
| FIDO-backed key | Uses an ecdsa-sk or ed25519-sk authenticator where supported. |
Environments that want a hardware-bound key operation. | Loss, damage, incompatibility, or unavailability of the authenticator can block the first step. |
| Password authentication | Uses the account password through the enabled password or PAM path. | When a password is required as the second factor. | Prompt behavior and password policy follow the distribution’s authentication stack. |
Password authentication versus keyboard-interactive behavior
The example uses the method name password. Some Linux installations expose prompts through keyboard-interactive authentication, often connected to PAM, rather than through the direct password method. These are not interchangeable names in AuthenticationMethods. If your intended second factor is a PAM-driven keyboard-interactive exchange, configure and enable the method that your distribution actually provides, then test the resulting sequence. Do not assume that a visible password prompt proves that the server is using the password method.
The essential rule remains the same: the method named after the comma must be enabled in the effective configuration, and it must be the method your client and PAM stack can complete. If you change from direct password authentication to keyboard-interactive behavior, validate both the server-side method and the client prompt flow before deploying the policy broadly.
How to verify the effective configuration
Read the daemon’s effective configuration, not only the file you edited. Your verification should answer four questions:
- Is
AuthenticationMethodsexactly the intended sequence for the account being tested? - Is public-key authentication enabled in that same scope?
- Is the password or intended PAM-based method enabled in that same scope?
- Do included files or
Matchblocks override any of those values?
Use the effective-configuration inspection facility and syntax-test command documented by your distribution. Check the configuration as the target account and connection context would see it when your platform’s tooling supports that distinction. Then perform a real login test: configuration output can show that a method is enabled, but only a new session confirms that the account’s key, client, password, and PAM path all work together.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common failure modes and fixes
The server accepts the key but never asks for a password
Look for a missing comma, an alternative list separated by whitespace, or an override that changes AuthenticationMethods for the tested account. Also confirm that you are testing a fresh connection; an already-authenticated session cannot demonstrate the second step.
Recommended Free Tools
The server asks for a password but rejects the login after a valid key
Verify that the configured password method is enabled and that the account password or PAM credentials are valid. If the installation uses keyboard-interactive PAM prompts, check whether the configured method name matches that stack. A password prompt alone does not establish that the required method completed successfully.
The key is rejected before the password prompt
Check that the public key is authorized for the target account and that the client is using the matching private key. A sequential policy intentionally stops when the first method fails; it will not fall back to password-only access.
The daemon refuses to reload
Use the open administrative session to run the distribution’s configuration test again and read the exact error. Inspect spelling, punctuation, included files, and the placement of any Match block. Correct the configuration, repeat the test, and reload only after it passes.
One user works while another does not
Compare their effective configuration and authorization scope. A per-user or per-group Match rule, a different authorized-key file, or a different PAM policy can produce different results even on the same server.
A hardware-backed key is unavailable
The FIDO authenticator is part of the first method, so the password cannot replace it. Use an already-authorized backup key or the console-based recovery procedure prepared for the server. Do not remove the last working administrative path until a replacement factor has been tested.
Recovery planning before enforcement
Requiring two methods changes the failure mode from “the password is unavailable” to “either factor can stop a login.” Prepare at least one recovery route before applying a global rule:
- Keep an authenticated administrative session open during rollout.
- Maintain a local or out-of-band console path where the platform provides one.
- Authorize a separately protected backup key for critical administrators.
- Document which account, key, password or PAM method, and configuration scope were tested.
- Decide how to revoke a lost software key or FIDO authenticator without disabling the remaining administrators.
Recovery planning is especially important for a hardware-backed implementation because the authenticator may be lost, damaged, incompatible with a client, or simply unavailable at the time of login.
Deployment checklist
AuthenticationMethods publickey,passwordis present in the intended scope.- The comma is present, so the methods are sequential rather than alternatives.
PubkeyAuthentication yesis effective for the target account.PasswordAuthentication yes, or the deliberately selected PAM-based method, is effective for the target account.- The target account has an authorized public key and access to its matching private key.
- Included configuration files and
Matchblocks have been reviewed. - The distribution’s syntax/configuration test passes.
- The SSH service has been reloaded using the distribution’s documented procedure.
- A new session completed the key prompt followed by the password prompt.
- The original administrative session remains available until that test succeeds.
Security and usability trade-offs
This policy provides a sequential two-method requirement, but it does not eliminate every risk. A stolen private key and a known account password can still satisfy the sequence. Conversely, losing either factor prevents access, which is why backup credentials and console recovery matter. FIDO-backed keys can bind the public-key operation to hardware, while software keys are usually simpler to distribute and automate. The right choice depends on whether your priority is hardware-bound key use, broad client compatibility, or straightforward operational recovery.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Apply the rule at the narrowest scope that meets your objective, test it with the actual account and client, and expand it only after the recovery procedure is proven. The directive is small; the surrounding effective configuration and operational process determine whether the result is secure and usable.
Quick Recap
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.
