What happens when SSH key login is enabled but password login is still allowed?

Why SSH keys alone do not close the login path

When password login stays enabled, ssh key authentication is only one allowed method, not the only one. That means the account is still reachable through any password-based path the server accepts, including guessable or reused passwords. The security gain from keys is real, but the exposure is not fully removed until password authentication is disabled for that service or account.

In practice, the difference is whether the attacker has one door or two. Key-based login raises the bar for routine guessing, but a surviving password path keeps the service exposed to automated password attacks and to any situation where a user password has already been stolen elsewhere.

What changes in attacker behaviour when both methods are accepted

Attackers do not need to defeat the key if they can still try the password route. That matters because password attacks scale well: credential stuffing, sprayed guesses, and reused-password testing are cheap to automate and can succeed even when the key policy is otherwise strong.

By contrast, SSH keys shift the security model toward possession of the private key and away from memorised secrets. If password auth remains, the server is effectively operating in a mixed-authentication mode, which expands the attack surface and weakens the practical assurance that the allowed login method is the one you intended.

Administrators sometimes assume that “keys enabled” means “password risk removed.” It does not. The strongest posture is to require key-only access for the intended users, then separately control who can enrol, store, and use those keys.

What good looks like in a hardened SSH configuration

A hardened setup makes the authentication path unambiguous: password login is disabled, only approved keys are accepted, and access is limited to the accounts that genuinely need SSH. For environments with stronger assurance needs, this is often paired with NIST SP 800-63 Digital Identity Guidelines guidance on stronger authenticators, plus service-side restrictions that keep the key from becoming a blanket pass to every system.

For control design, the key question is not whether SSH “supports keys,” but whether the authentication policy still permits fallback authentication. If it does, the control is only partial. That same least-privilege logic is reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls and in PCI DSS v4.0 expectations around restricting access and limiting interactive use of system accounts.

Where teams want a broader control model, NIST Cybersecurity Framework 2.0 is useful for aligning the decision with access governance, protective configuration, and detection expectations rather than treating SSH as a one-off hardening task.

Risk and Threat Considerations

Leaving password login enabled preserves a predictable attack path even when key-based login exists. That creates avoidable exposure to brute force, password spraying, and credential stuffing, and it also leaves the system vulnerable if the user’s password is already known from another breach.

Failure mechanism: The SSH service continues to accept a second authentication factor that is easier to guess, reuse, or automate against than a private key, so the attacker simply targets the weaker path instead of the stronger one.

Impact: An account that appears to be protected by keys can still be compromised through password authentication, which can lead to server access, lateral movement, command execution, and further credential harvesting.

Practitioner Guidance

What to verify: Confirm that password authentication is disabled at the service level for every account that should be key-only, and verify that no inherited configuration, jump host exception, or management account silently re-enables it. The control is only real when the effective configuration matches the intended policy.

Decision rule: If an SSH account can still authenticate with a password, treat the setup as partially hardened, not secure-by-key. Reserve password fallback only for exceptional recovery use cases, and isolate those exceptions from normal administrative access.

What practitioners underestimate: Mixed-mode authentication creates a false sense of assurance because the stronger method is visible and the weaker one is easy to forget. The practical objective is to remove the fallback path, then manage key lifecycle, approval, and revocation with the same discipline as any other privileged access mechanism.

Practitioner takeaway: SSH keys improve login security only when they are the only accepted path for that access surface, because any remaining password option preserves the simplest route for automated compromise.

Related resources from NHI Mgmt Group

• What happens when a master password is weak but the vault format still uses slow key derivation?
• Why do ephemeral credentials still leave risk in machine access models?
• What breaks when a federated NHI still has password or key fallback paths?
• Who is accountable when a stale password login path is still available after SSO adoption?