An SSH server can accept public keys, passwords, keyboard-interactive checks, host-based credentials, GSSAPI, and other methods. Enabling several of them does not necessarily require a user to complete several. The AuthenticationMethods directive is the place where sequencing is defined, and its punctuation changes the result.

Lists have different meanings

The OpenSSH manual describes AuthenticationMethods as one or more comma-separated lists. A comma inside a list means the methods in that list must all succeed, in order. A space between lists creates alternatives. For example, publickey,keyboard-interactive represents one sequence, while publickey keyboard-interactive offers two single-method alternatives.

Both forms are compact, so a review can miss the difference. A policy intended to require a key and a second factor can become a policy that accepts either a key or a keyboard check. The server still logs successful authentication, so the mistake may look normal until someone tests the shortcut.

Every method must be enabled

AuthenticationMethods does not turn on the methods it names. The corresponding server settings must permit them. If KbdInteractiveAuthentication is disabled, adding keyboard-interactive to the sequence does not create a working second factor. If PubkeyAuthentication is off, a public-key entry cannot satisfy the policy.

The effective configuration also includes included files and match blocks. Run sshd -T against the installed configuration and inspect the merged result. Review the source files as well, because a later match block can change the available method for a group or address range. Keep a copy of the parsed output with the change record.

Public-key reuse is separately constrained

The manual notes that when publickey appears more than once in a method list, sshd checks that a key used successfully earlier in that authentication exchange is not reused for a later publickey step. That protects a sequence from appearing to require two independent key proofs while accepting the same key twice.

This does not turn two public-key steps into a second factor. The user still possesses the same kind of credential. A meaningful second factor should introduce a different authentication mechanism or an independently controlled device and verifier.

Test the shortcut

Create local test accounts and connect from a controlled address. Exercise the intended path and at least one path the policy should reject. Use verbose client output to see which methods the server offers, but do not copy private keys or token values into logs.

Test with the account's real group membership and source network. A match block for administrators may not apply to the test account. Test both an ordinary user and a privileged one, then repeat after a configuration reload. Confirm that a failed first step sends the client to the next required method rather than granting a session.

Roll out with a fallback window

Changing an SSH policy can lock out the team that needs to repair it. Prepare a separate maintenance path with restricted network access and audited access. Keep the old policy available for a defined rollback window, and check that the rollback file is itself syntactically valid.

Before closing the change, inspect authentication logs for the intended sequence and for unexpected single-method successes. The useful evidence is not a line that says an administrator logged in. It is the sequence of accepted methods, tied to the account and source address the policy was meant to cover.

References