Enforcing Password Authentication for SSH: A Practical Guide

In some environments, organizations must conform to policies that require password-based SSH access rather than key-based authentication. This may be due to legacy applications, specific audit requirements, or operational constraints where password rotation and centralized authentication are already in place. If policy requires you to ssh force use password on your servers, this guide explains the steps, trade-offs, and safeguards to implement this configuration responsibly.

Understanding SSH authentication methods

SSH supports several authentication methods that determine how a user proves their identity. The most common are:

Password authentication: The user enters a password associated with their account.
Public key authentication: A cryptographic key pair is used, typically more secure and convenient for automated access.
Keyboard-interactive authentication: A challenge–response flow that can include one-time codes or tokens, often managed by PAM.
GSSAPI/Kerberos: Generic security services that integrate with centralized authentication systems.
Host-based authentication: Trust established between hosts.

For many administrators, password authentication is simpler to manage in some scenarios, but it comes with higher risk if not properly controlled. If you want to force password usage, it means prioritizing or restricting login attempts to the password path and disabling alternatives that rely on public keys or other methods.

Why you might want to force password login

There are several legitimate reasons to require a password-based SSH login in certain environments:

Compliance requirements: Some policies mandate that every user’s authentication method be password-based for auditability or compatibility with legacy systems.
Operational constraints: In mixed environments, some hosts may not yet support public key distribution, or administrators prefer a centralized password rotation workflow.
Temporary transitions: During a phased migration from password to key-based access, a temporary enforcement of password authentication can ensure continuity.

However, it’s important to balance these reasons with security implications. Passwords are susceptible to guessing and brute-force attacks, and relying solely on passwords can increase the attack surface if the server is exposed to the internet. The following steps show how to implement the policy thoughtfully and securely.

Security considerations you should plan for

Strengthening passwords: Enforce strong password policies, including length, complexity, and regular rotation where feasible.
Rate limiting and monitoring: Deploy tools like Fail2ban or similar to monitor failed attempts and block abusive IPs.
Network controls: Use firewalls or security groups to restrict SSH access to trusted networks or VPNs.
Auditing and logging: Enable detailed SSH logs and monitor for suspicious login patterns.
Fallback and recovery: Ensure you have a safe recovery path in case you lock yourself out of an SSH-enabled system.

When you explicitly force password authentication, you should also consider how PAM and other modules interact with login flows. If you later decide to reintroduce multi-factor authentication, plan for a careful transition because forcing a single method can complicate later changes.

Step-by-step: configuring SSH to force password authentication

The following steps outline a straightforward approach to enforce password authentication on a typical Linux server. The exact file paths and service names may vary slightly between distributions (for example, Debian-based vs. Red Hat-based systems).

Back up the SSH configuration

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Edit the SSH server configuration
Open the SSH daemon configuration file and apply the following settings. These collectively ensure that only password authentication is used, and public-key authentication is disabled to truly “force password” login.
```
# Enforce password authentication and disable key-based login
PasswordAuthentication yes
PubkeyAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods password
```

Apply the changes

Reload or restart the SSH service to apply the new configuration. The exact command depends on your init system.

# Systemd-based systems (most modern Linux distros)
sudo systemctl reload sshd
# If reload is not available, you can use restart
# sudo systemctl restart sshd

Validate connectivity
Test login from a client to ensure password prompts are delivered. It’s wise to perform this test from a non-privileged account and, if possible, from a different network segment to avoid locking yourself out.
```
ssh user@your-server.example.com
```
Optional hardening: Match blocks
If you want to apply password-only enforcement to specific users, groups, or hosts, you can add a Match block in sshd_config. This provides controlled rollout while keeping global behavior intact for other accounts.
```
Match User specificuser
  PasswordAuthentication yes
  PubkeyAuthentication no
```

If your distribution uses PAM and you rely on PAM modules for authentication, you may also see references to keyboard-interactive methods. The settings above explicitly disable keyboard-interactive and other non-password avenues, ensuring a consistent path for authentication across sessions.

Testing and validation tips

A careful validation plan helps prevent accidental lockouts. Consider the following:

Test with a non-privileged account before applying changes to privileged accounts (like root or admin users).
Keep a separate console or out-of-band access method available in case SSH access is temporarily unavailable.
Review SSH logs after the change. Look for authentication failures and confirm that password prompts are being presented as expected.
Verify that automated tools or scripts that rely on key-based authentication are updated to use password login or are temporarily disabled during the transition.

Rollout strategy and rollback plan

Deploying a restrictive authentication policy should include a rollback plan in case something goes wrong. A practical rollback plan includes:

A ready-made backup of sshd_config (see the backup step above) and a saved copy of any Match blocks you use.
Documentation of the exact steps to revert to the prior configuration, including re-enabling PubkeyAuthentication and setting PasswordAuthentication back to no if you decide to revert.
A controlled maintenance window if possible, to closely monitor the impact on users and services.

Remember: forcing password authentication means you are removing the convenience and security benefits of key-based access for SSH. Consider a staged approach, starting with a subset of hosts or users, and progressively expanding after verifying stability and security controls.

Alternatives and best practices worth considering

In some cases, you may not want to keep password authentication as the sole method. Consider these balanced alternatives if you reassess the policy later:

Hybrid approach: Use AuthenticationMethods to require both password and a second factor (for example, a TOTP code) if your organization supports multi-factor authentication. Note that this would change the simple “password only” flow and would not satisfy a strict password-only requirement.
Privileged access management (PAM): Centralize password management, session recording, and approval workflows to reduce risk when passwords are the primary factor.
Stronger network controls: Pair password authentication with IP allowlists and VPN-only access to reduce exposure.
Monitoring and alerting: Implement SSH login anomaly detection to detect brute-force activity early.

Conclusion

Choosing to enforce password authentication for SSH is a decision that carries security and operational implications. By carefully configuring sshd_config to enforce the password pathway, validating changes through controlled testing, and layering additional protections such as rate limiting and network controls, you can achieve policy compliance while maintaining control over access. If policy requires you to ssh force use password, follow the steps outlined here, but keep a clear rollback plan and ongoing monitoring to respond quickly to any issues. Regular reviews of authentication methods, password hygiene, and network exposure will help ensure that SSH access remains secure and auditable over time.