Enable SSH Password Authentication: A Practical Guide

Remote administration is a cornerstone of modern IT operations, and SSH remains the most common protocol for secure shell access. While many administrators prefer key-based authentication for its strong security posture, there are situations where you may need to enable SSH password authentication. This guide explains how to enable SSH password authentication responsibly, what risks to consider, and practical steps to minimize exposure while keeping your servers accessible for legitimate users.

Understanding SSH password authentication

SSH password authentication allows users to log in with a username and password rather than relying solely on cryptographic key pairs. When enabled, the SSH daemon consults the system’s password database and, optionally, PAM (Pluggable Authentication Modules) to verify credentials. The feature is convenient for onboarding, temporary maintenance, or devices that cannot easily support SSH keys. However, it also expands the attack surface because password-based logins can be more susceptible to brute-force attempts, credential stuffing, and human error. Therefore, it is crucial to implement layered security measures if you choose to enable SSH password authentication.

Key considerations before enabling

Risk assessment: Understand that password authentication can increase the likelihood of unauthorized access if passwords are weak or reused across services.
Access controls: Plan to restrict root access and limit which users can authenticate over SSH.
Monitoring: Prepare to monitor login attempts, and have an incident response plan in case of suspicious activity.
Defense in depth: Combine password authentication with rate limiting, fail2ban, or similar tools, and consider enabling two-factor authentication where possible.

Security-friendly conditions for enabling

If you decide to enable SSH password authentication, apply these best practices to reduce risk:

Disable password authentication for all privileged accounts, or at least require non-root users to authenticate with passwords while root access remains restricted.
Combine password authentication with PAM to leverage additional verification factors if your environment supports it.
Implement an allowlist of users who can authenticate via SSH and review this list periodically.
Use fail2ban or an equivalent tool to block repeated failed login attempts from the same IP address.
Keep your SSH server up to date and minimize exposed attack surfaces by configuring firewalls and limiting accessible networks.

Step-by-step: How to enable SSH password authentication

Back up the current SSH configuration
Before making changes, create a safety net. Copy the existing configuration to a backup file so you can roll back if something goes wrong.
```
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
```
Edit the SSH daemon configuration
Open the SSH configuration file and ensure the password-based authentication options are enabled. The exact lines you adjust are PasswordAuthentication and, optionally, ChallengeResponseAuthentication. If you use PAM, you may want UsePAM to Yes as well.
```
sudo nano /etc/ssh/sshd_config
```
In the editor, confirm or set the following lines:
```
PasswordAuthentication yes
ChallengeResponseAuthentication yes
UsePAM yes
```
Optional lines you may also consider, depending on your security stance:
```
PermitRootLogin prohibit-password
```
Save and exit the editor.
Decide how to handle root login
It is common and prudent to disallow direct root login when password authentication is enabled. This reduces the risk that a compromised account with root privileges is obtained via a brute-force password attack.
Reload or restart the SSH service
Apply the changes by reloading or restarting the SSH daemon. The exact command depends on your distribution and init system.
```
# Systemd-based systems
sudo systemctl reload sshd
# If reload fails, you can restart
sudo systemctl restart sshd
```
If your system uses a different service name (for example, ssh on Debian/Ubuntu), substitute accordingly:
```
sudo systemctl reload ssh
sudo systemctl restart ssh
```
Test the configuration from a separate session
Open a new terminal and attempt a login with a password to ensure the changes work as expected.
```
ssh username@your-server-address
```
If prompted for a password and you can log in, the configuration change is functioning. If not, check the sshd logs for clues:
```
sudo journalctl -u sshd -e
# or
sudo tail -n 100 /var/log/auth.log
```

Verify options at runtime
Confirm that the daemon is actually using the intended settings and that password authentication is enabled:

grep -E "PasswordAuthentication|ChallengeResponseAuthentication|UsePAM" /etc/ssh/sshd_config
# Optional runtime verification
sudo sshd -T | grep -E "passwordauthentication|challengeresponseauthentication|usepam"

Implement post-enable protections
If you are enabling password authentication on a server exposed to the internet, consider:
- Setting a strict login window with fail2ban
- Configuring a firewall to limit SSH access to trusted networks or a VPN
- Enforcing strong password policies and account lockouts
- Enabling two-factor authentication if your platform supports it
- Using per-user restrictions with AllowUsers or AllowGroups in sshd_config

Testing, verification, and troubleshooting

Thorough testing is essential after enabling SSH password authentication. Start with a test connection from a different device or network to simulate a real login. If you run into issues, check common areas:

Syntax errors in /etc/ssh/sshd_config can prevent the service from starting. Always run a configuration syntax check if possible and verify the daemon’s status after editing.
Permissions on the sshd_config file and the user’s home directory can affect login. Ensure permissions are secure and not overly permissive.
Conflicting authentication methods (e.g., publickey authentication) may override or complicate password logins. Confirm the intended authentication method is active.
If you rely on PAM for account restrictions or MFA, ensure the PAM stack is correctly configured and the necessary modules are installed.

During testing, document the observed behavior and adjust the configuration accordingly. If you face persistent issues, revert to the backup configuration you saved earlier and reattempt with a refined approach. Reverting can be done with:

sudo mv /etc/ssh/sshd_config.bak /etc/ssh/sshd_config
sudo systemctl restart sshd

Best practices and sensible alternatives

Even if you can enable SSH password authentication, consider whether it is the best fit for your environment. A few best practices and alternatives can help you balance usability and security:

Prioritize SSH key-based authentication for day-to-day administration and reserve password authentication for scenarios that require it temporarily.
Use passphrases for SSH keys and enable SSH agent forwarding cautiously.
Implement two-factor authentication (2FA) when possible, as an additional layer beyond password authentication.
Limit SSH exposure with network controls, such as firewall rules, VPN access, or bastion hosts, so that only trusted networks can attempt logins.
Regularly audit user access and remove any accounts that no longer require SSH permissions.
Keep your SSH software up to date and monitor for security advisories related to SSH daemons and PAM modules.

Common pitfalls and how to avoid them

Enabling SSH password authentication is not a set-and-forget action. Watch out for these common problems:

Leaving root login enabled with password authentication increases risk. Use a non-root user for SSH and elevate privileges with sudo after logging in.
Weak passwords or password reuse across services can undermine security. Enforce strong password policies and consider password managers for administrators.
Overexposure of SSH. If your server is publicly reachable, take additional measures like rate limiting and IP whitelisting.
Lack of monitoring. Without proper monitoring, brute-force attempts may go unnoticed. Use logging, alerting, and automated blocks.

Conclusion

Enabling SSH password authentication can be a necessary step in certain environments, such as temporary access scenarios or legacy systems. However, it requires careful planning, tightened controls, and ongoing monitoring to mitigate associated risks. By following the steps above—backing up your configuration, enabling PasswordAuthentication wisely, restricting root access, restarting the SSH service, and layering protections like fail2ban and network controls—you can successfully enable SSH password authentication while maintaining an acceptable security posture. If possible, pair password authentication with additional safeguards or consider transitioning toward key-based authentication as the long-term default to reduce exposure and simplify access management. The goal is to keep operations smooth for legitimate users while making it substantially harder for unauthorized access to succeed. By thoughtfully enabling SSH password authentication and implementing robust defense-in-depth measures, you can maintain secure, reliable remote administration across your infrastructure.