Disable SSH password authentication on your clients

Martin Stecher March 31, 2025

There are many best practice guides all over the Internet, guiding administrators on how to disable password authentication on an SSH server by adding PasswordAuthentication no to the sshd_config file. There are good arguments for only allowing public key authentication for server logins.

But did you know that the same setting also exists for the ~/.ssh/config file on your client computer? We will review this topic and consider whether this setting might be even more important - especially if you are an administrator responsible for corporate client configurations.

Traditionally, SSH security is discussed from a server-side viewpoint

Most articles on this topic across the Internet discuss whether password-based logins to your SSH servers shall be allowed or forbidden. A common opinion is that public key user authentication is more secure if the private key of the public key authentication is secured by a passphrase (which the server cannot verify).

The best approach might be to switch to certificate-based authentication for users and create certificates with rather short validity periods while reviewing the integrity and security of the corresponding private key regularly.

However, there is surprisingly little discussion as to how much password authentication is a risk to your clients and even more so to the security of your corporate identities!

Attackers stealing your central passwords

SSH users are used to the fact that some servers grant immediate access via the user's public keys while other servers require the user to log in via password.
When users log in from multiple clients and the required private/public key pair is not available everywhere, they benefit from servers allowing to fallback to password-based authentication as an alternative.

This opens up a special attack vector:

• Password reuse: Users tend to reuse passwords on different SSH servers.
• Phishing attacks: Attackers exploit phishing emails to redirect users to fake servers.
• Stolen credentials: Once a password is entered, it's compromised. Even if the connection is encrypted, a malicious server receives the full credentials.

This is particularly risky in corporate environments as users may try their standard corporate credentials, assuming that the server is connected to their corporate directory.

SSH sends the full password to the server

Other protocols use some kind of challenge-response mechanism to only send a hash of a password that a server can verify but as SSH was built on top of the normal shell login, it requires the full password and use that to login the user locally.

SSH negotiates packet encryption and enables that encryption before the user authentication steps in the protocol starts, so that the password transfer is end-to-end encrypted between client and server and a malicious intermediate cannot capture that password.

However, if the server is malicious, it will receive the full user credentials and can copy them and then exploit that information on other systems:
Once a user has shared a password to an SSH server that is not fully trusted, the user credentials are immediately compromised.

Prevent unintended password exposure

Cloud Fellows recommends disabling password authentication on the client side for all SSH servers and re-enabling it only for trusted servers where necessary.

For this, open the ~/.ssh/config file and locate the Host * section, which applies to all unspecified servers. Then add the PasswordAuthentication no directive to this section.

If that section does not yet exist in your config file, you can simply add it to the end of the config file as follows:

# Disable password authentication by default
Host *
PasswordAuthentication no

This will prevent that your ssh client will start password authentication even if the server offers that authentication option!

Note, that this option will also disable password authentication for all servers, even those listed earlier in your config file explicitly.
In order to re-enable password authentication for those selected servers, simply add the PasswordAuthentication yes directive for those.

For example:

Host trusted-1.example.org
User john
IdentityFile ~/.ssh/id_ed25519
# This server uses public key auth
# We will keep password auth off

Host trusted-2.example.org
User john
PasswordAuthentication yes
# This server requires password auth
# and we trust it. So enable it.

Host *
PasswordAuthentication no
# Disable password authentication by default

By making this small change, you prevent unintended credential leaks and improve corporate security. Every IT admin should implement this as a best practice. And if you are a security administrator for a corporate domain, you may want to ensure such an SSH configuration is rolled out to all your corporate clients.

Network options to monitor and prevent SSH password attacks

As explained above, the SSH protocol first establishes a secure end-to-end encrypted session between the client and the server before it starts the user authentication process.

Therefore, it is impossible for a normal firewall or intrusion protection solution in your network to identify whether a server asks for password authentication and whether the user sends a password to the server.

However, such a solution could prevent connections to any not-explicitly trusted server in the first run.

For a full solution for any host, you’ll need a true SSH Gateway solution that acts as a trusted intermediate between the client and server and maintains separate encrypted connections to the client and to the server and then enforces a policy to manage the login process.