Configuring SSH Password Authentication: A Practical Guide

SSH password authentication remains a straightforward way to secure remote access, especially in environments where managing a large set of public keys is impractical. This guide walks through how to configure password-based login using the SSH client and server settings, clarifies the difference between ssh_config and sshd_config, and outlines best practices to balance usability with security. While key-based authentication is often preferred, understanding SSH password authentication in depth helps you implement robust, auditable access controls when needed.

Understanding the basics: SSH password authentication vs. key-based access

At its core, SSH password authentication allows a remote user to log in by presenting a username and password. This method is easy to deploy because it does not require distributing and managing cryptographic keys. However, it has some drawbacks compared to key-based authentication. Passwords can be weaker than cryptographic keys, are susceptible to phishing or guessing, and are harder to rotate or revoke in bulk. For this reason, many organizations use a hybrid approach: keep SSH password authentication enabled for fallback or initial access, but favor key-based authentication as the default method. In addition, enabling two-factor authentication or PAM-based controls can significantly strengthen security when password authentication is in use.

Key components: ssh_config vs. sshd_config

To configure SSH access, you must understand two distinct configuration files:

• ssh_config — the SSH client configuration file. It lives on the machine you are connecting from and defines how the client behaves, including how it presents authentication methods to remote servers.
• sshd_config — the SSH daemon configuration file. It lives on the remote server and controls which authentication methods are allowed, default shells, access controls, and more.

When you adjust password authentication behavior, you generally modify sshd_config on the server to enable or disable the server’s acceptance of passwords, and you may adjust ssh_config on the client to influence which methods the client tries first. A careful combination ensures predictable and auditable access.

Enabling SSH password authentication on the server

To allow SSH password authentication, you need to update the server’s SSH daemon configuration. The key directive is PasswordAuthentication, and you may also adjust ChallengeResponseAuthentication and UsePAM depending on your PAM setup.

# /etc/ssh/sshd_config
PasswordAuthentication yes
ChallengeResponseAuthentication yes
UsePAM yes
PermitRootLogin prohibit-password

After editing sshd_config, restart the SSH daemon to apply changes. On most systems you can use one of these commands:

• sudo systemctl restart sshd
• sudo service sshd restart

Notes and tips:

• If PasswordAuthentication is set to no, the server will refuse password-based login regardless of client configuration. This is a common default in hardened environments.
• Setting PermitRootLogin to a value like prohibit-password or no can prevent direct root access, reducing the impact of brute-force attacks.
• With UsePAM enabled, the PAM stack determines password quality and any additional factors (such as 2FA). Ensure PAM is configured to align with your security goals.

Enforcing password authentication on the client side (ssh_config)

The client-side configuration can influence whether password authentication is attempted and in what order. The two main directives are PreferredAuthentications and PasswordAuthentication. If you want to ensure the client uses password authentication, you can configure these values in ~/.ssh/config or the system-wide /etc/ssh/ssh_config:

# ~/.ssh/config
Host example.com
  User alice
  PreferredAuthentications publickey,password
  PubkeyAuthentication yes

If you want to explicitly allow password-based login while still permitting keys, include both methods in the preferred list, with the important caveat that the server must support them. If you want to prefer passwords over keys for a particular host, you can reorder the list as password,publickey, though this is less common in production settings where key security is prioritized.

Practical workflow: configuring and testing

Here is a practical workflow you can follow to enable and verify SSH password authentication:

1. On the server, back up the current sshd_config and review the existing authentication methods.
2. Edit sshd_config to enable PasswordAuthentication and, if applicable, enable PAM integration.
3. Reload or restart the SSH service to apply changes.
4. From a client, attempt a login using a test account with a known password, watching the verbose output for authentication steps (ssh -v user@host).
5. Verify that authentication methods include password and, if using PAM or 2FA, that those checks pass as expected.
6. Implement monitoring and logging to capture failed attempts and successful logins for auditing.

When testing, look for messages like “password authentication accepted” or “Authentication succeeded” in the SSH trace. If you see “Permission denied, please try again,” revisit both server and client configurations, confirm the password, and check whether any PAM modules or 2FA prompts are involved.

Common pitfalls and troubleshooting

• Incorrect file syntax: A misplaced directive or syntax error in sshd_config can prevent SSH from starting. Always run sshd -t to test the configuration before reloading the service.
• Discrepancy between server and client settings: If the server allows password authentication but the client refuses, you may have ssh_config restricting PasswordAuthentication or prioritizing another method.
• PAM-related failures: If you enable UsePAM and your PAM stack requires additional factors, ensure those prompts are reachable and the user has access to the second factor.
• Brute-force risk: Password-based access is more vulnerable to brute-force attempts. Implement account lockout, rate limiting (fail2ban, sshguard), and consider using a non-default port to reduce noise.
• Root login considerations: If root login is allowed with a password, it increases risk. Prefer disabling root password login and using a non-root user with sudo privileges.

Security posture: when to use SSH password authentication

In modern deployments, SSH password authentication is often reserved for specific scenarios:

• Temporary access during onboarding or troubleshooting when key management is not yet in place.
• Environments where automated key provisioning is impractical or restricted by policy.
• Fallback access during incidents where keys are temporarily rotated or rotated keys are not immediately available.

Even in these cases, aim to harden the environment:

• Keep sshd_config updated with current security guidelines and disable password authentication when possible.
• Use strong, unique passwords and enforce password policies through PAM or system settings.
• Prepare two-factor authentication or hardware security modules as part of the authentication chain.
• Limit access to essential users and hosts, and enable logging for all SSH events.

Best practices and recommended patterns

To maintain a secure and manageable SSH environment, consider the following best practices when dealing with SSH password authentication:

• Prefer key-based authentication as the default method and use password authentication only as a fallback or for initial access when keys are not yet deployed.
• Disable root password authentication by setting PermitRootLogin no or prohibit-password and require non-root accounts for SSH access.
• Combine password authentication with multi-factor authentication (MFA) to add an extra security layer.
• Regularly audit access permissions and rotate credentials where applicable, and monitor SSH login attempts for anomalies.
• Keep your SSH software up to date and apply security patches promptly to reduce the risk surface.

Conclusion

Configuring SSH password authentication involves a simple set of steps, but it sits at the crossroads of usability and security. By understanding the roles of ssh_config and sshd_config, you can craft a configuration that aligns with your operational needs while maintaining robust protections. Whether you enable password authentication as a temporary measure or maintain it as a controlled option, pairing it with strong PAM policies, MFA, and vigilant monitoring will help you manage access without compromising security. Remember that the long-term best practice for remote administration is to rely on key-based authentication, fortified by MFA and proper access controls, while keeping password-based paths tightly controlled and auditable.