1. Overview
The default values in the OpenSSH daemon configuration file allow an SSH client user to log in to the server using a password. However, security best practices recommend turning off this authentication mode because it’s vulnerable to brute-force attacks. Under specific conditions, an SSH server may allow password login despite turning off this mode.
In this tutorial, we’ll study the scenarios allowing successful password login with ssh despite setting PasswordAuthentication to no. Initially, we’ll go over SSH login mechanisms. Then, we’ll learn about the scenarios behind this issue. Furthermore, we’ll preview and apply the sshd configuration. After that, we’ll examine how some settings could override the PasswordAuthentication setting due to higher precedence. Finally, we’ll study the effect of the UsePAM and KbdInteractiveAuthentication directives on password authentication.
We ran all scripts on Debian 12 (Bookworm) OS in Bash 5.2.15 with OpenSSH version 9.2p1-2+deb12u2. The IP address of our SSH server is 10.0.0.12.
2. SSH Login Mechanisms
OpenSSH supports six authentication mechanisms configurable via the AuthenticationMethods directive in /etc/ssh/sshd_config:
- gssapi-with-mic: GSSAPI (Generic Security Services Application Program Interface) with MIC (Message Integrity Code), usually set up using Kerberos as the GSSAPI implementation
- hostbased: Client host identification for authentication
- keyboard-interactive: Supports authentication styles from login.conf via keyboard-interaction
- none: Passwordless access with PermitEmptyPasswords enabled
- password: Password-based authentication
- publickey: PKI (Public Key Infrastructure) based authentication with the private key on the client side
The default value for AuthenticationMethods is any. However, turning on individual mechanisms through their corresponding directives is necessary, like setting KbdInteractiveAuthentication to yes for keyboard-interactive login.
3. Successful Login With ssh in Spite of “PasswordAuthentication no” Setting
Two scenarios could allow password login despite setting PasswordAuthentication to no:
- some configuration overrides the PasswordAuthentication value to yes
- both UsePAM and KbdInteractiveAuthentication directives evaluate to yes
These cases depend on the runtime sshd configuration for incoming client connections. Before examining both scenarios, we’ll preview and apply the configuration.
3.1. Checking sshd Configuration
Let’s run the sshd command with the extended test mode option -T. This option lets us preview the configuration by checking the validity of the configuration files: /etc/ssh/sshd_config and any file included using the Include directive.
Let’s print the evaluated configuration to stdout:
$ sudo sshd -T
...
usepam yes
...
pubkeyauthentication yes
...
passwordauthentication no
kbdinteractiveauthentication yes
...
The truncated output above shows only the lines relevant to us. Each line contains an sshd directive and its applicable value separated by a whitespace. Enabling an alternate mechanism, such as public-key authentication, is important before turning off password login. Otherwise, we could lose access to the server.
3.2. Checking Conditional sshd Configuration
Match directives that define values conditionally could be present in the configuration files, such as a custom configuration file /etc/ssh/sshd_config.d/baeldung-match.conf:
Match User baeldung
PasswordAuthentication yes
sshd provides the -C option to preview the configuration by providing the connection specification condition:
$ sudo sshd -T -C user=baeldung
...
passwordauthentication yes
...
Thus, the Match setting above allows password authentication for the user baeldung.
3.3. Checking sshd Configuration in Debug Mode
sshd debug mode supports up to three levels of debugging logs.
Let’s use the debug logs to check how sshd sets the PasswordAuthentication directive. We’ll set debug to level three via -ddd, specify /dev/stdout to -E to append logs to stdout, and filter lines containing this directive using grep. Additionally, we’ll check for any matches for our user baeldung:
$ sudo sshd -T -ddd -E /dev/stdout -C user=baeldung | grep -iE --color=auto "(match found)|passwordauthentication"
debug3: /etc/ssh/sshd_config:58 setting PasswordAuthentication no
debug3: match found
debug3: /etc/ssh/sshd_config.d/baeldung-match.conf:2 setting PasswordAuthentication yes
passwordauthentication yes
Here, the last line is the final configuration evaluated for this directive. The debug lines show that sshd found a match in baeldung-match.conf and set the value to yes.
3.4. Applying sshd Configuration
Let’s apply the configuration by restarting sshd using systemctl:
$ sudo systemctl restart sshd
Any configuration change made previously will now apply to new SSH connections. If we modify any file after running this command, sshd will apply the changes only when we restart the daemon.
4. sshd Configuration Precedence Overriding PasswordAuthentication
Let’s study how the placement of PasswordAuthentication could determine whether some other occurrence of the same directive overrides its value.
sshd follows a simple strategy for the configuration precedence:
- sshd applies the first parsed value of a directive
- values parsed under a Match directive that evaluates to true take the highest precedence
Let’s check how certain directives and CLI options influence the configuration precedence.
4.1. Include Directive and Included Files
An Include directive supports adding multiple external sshd configuration files. /etc/ssh/sshd_config includes the files in the directory /etc/ssh/sshd_config.d by default:
Include /etc/ssh/sshd_config.d/*.conf
Here, the placement of the Include directive and the order of specifying the file paths to include determine the parse order. A wildcard “*” expands to the filenames in the ASCII code order.
If we use Include in a line above the PasswordAuthentication no line, then the included file takes precedence:
$ sudo cat /etc/ssh/sshd_config.d/passwd-auth.conf
PasswordAuthentication yes
Similarly, directives defined before any Include directive take priority over any included file.
4.2. sshd -o Option
sshd evaluates option -o before the /etc/ssh/sshd_config file.
Let’s test the effect by passing -o PasswordAuthentication=yes to sshd with the -T option:
$ sudo sshd -T -o PasswordAuthentication=yes | grep -i --color=auto "passwordauthentication"
passwordauthentication yes
Thus, running sshd with values passed to this option will override the global configuration.
4.3. Match Directive
Both /etc/ssh/sshd_config and included configuration files may contain multiple Match blocks. The directives defined immediately below a Match directive apply to connections that satisfy the provided condition:
Match Host 10.0.0.11
PasswordAuthentication yes
The block above allows password authentication for connections coming from the host 10.0.0.11.
The order of placing a Match block matters because values found in the first true Match block take precedence over the corresponding values in subsequent true blocks. sshd evaluates the truth value of the Match condition at runtime.
Additionally, Match All is a special case always evaluated as true. Let’s consider its effect if present in any configuration file:
Match All
PasswordAuthentication yes
Now, we’ll run the sshd extended test mode with -o PasswordAuthentication=no:
$ sudo sshd -T -o PasswordAuthentication=no | grep -i --color=auto "passwordauthentication"
passwordauthentication yes
In this way, Match directives override the global configuration, including the -o option. Therefore, checking the configuration files to ensure that no other occurrence of PasswordAuthentication overrides the no setting is essential.
5. UsePAM and KbdInteractiveAuthentication Directives
On the one hand, the UsePAM directive determines whether sshd will use the PAM (Pluggable Authentication Module) interface. This interface provides a set of common libraries that Linux programs like login and sudo can use for authentication, account, password, or session management.
On the other hand, KbdInteractiveAuthentication allows a keyboard-interaction-based login, which relies on passwords as the default authentication style. This directive deprecates ChallengeResponseAuthentication.
Enabling both UsePAM and KbdInteractiveAuthentication activates keyboard-interactive authentication:
$ sudo sshd -T | grep -iE --color=auto "usepam|kbdinteractiveauthentication"
usepam yes
kbdinteractiveauthentication yes
SSH server prompts the client user to provide their password in this mode:
$ ssh [email protected]
([email protected]) Password:
Here, *the prompt “(user@server) Password:” is slightly different from the password authentication prompt, which shows “user@server’s password:“*.
Now, let’s set KbdInteractiveAuthentication to no in /etc/ssh/sshd_config, apply the changes, and try logging in again:
$ ssh [email protected]
[email protected]: Permission denied (publickey).
As shown above, this user can no longer log in using the password.
6. Conclusion
In this article, we examined the two reasons behind a successful login with ssh despite setting the PasswordAuthentication directive to no, namely sshd overriding the no setting due to another occurrence of this directive with a higher precedence set to yes, and the combined activation of UsePAM and KbdInteractiveAuthentication.
Firstly, we saw different SSH login methods. Then, we understood the two causes behind this issue, ran commands to preview the sshd configuration with debugging and conditions, and applied the changes. After that, we learned how certain configurations could override the values provided in /etc/ssh/sshd_config, such as through the sshd -o option, the Include directive and external configuration files, or the Match directive. Lastly, we studied how enabling UsePAM and KbdInteractiveAuthentication together allows password login.