What is the difference between SSH password authentication and public key authentication?

Why This Matters for Security Teams

SSH authentication is often treated as a simple login choice, but the real issue is how much trust a server places in the first credential presented. Password authentication depends on shared secrets that can be guessed, reused, phished, or harvested from other breaches. Public key authentication replaces that exposure with proof of possession of a private key, which is safer when keys are protected, rotated, and scoped properly. For teams managing privileged access, that difference affects auditability, automation, and blast radius.

It also matters because SSH is frequently the control plane for servers, containers, and administrative workflows. A weak SSH pattern can undermine broader identity hygiene, especially when it overlaps with the same NHI problems seen in the Ultimate Guide to NHIs — What are Non-Human Identities and breach patterns discussed in the Twitter Source Code Breach. NHI Mgmt Group notes that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which is why the choice of SSH method should be viewed as part of access risk, not just convenience.

In practice, many security teams discover the weakness of password-based SSH only after a credential has been reused, sprayed, or exposed in an incident response investigation.

How It Works in Practice

Password authentication is straightforward: the client submits a user name and password, and the SSH daemon checks whether the shared secret matches. That simplicity makes it easy to deploy, but it also means the password must remain secret everywhere it travels through the human or operational process. Public key authentication changes the model. The server stores an approved public key, while the client proves possession of the matching private key during the handshake without sending the private key itself.

That difference creates several operational advantages:

• Passwords can be brute-forced or reused across systems; private keys are not transmitted and are harder to exploit remotely.
• Keys can be paired with passphrases, hardware-backed storage, or agent controls to raise protection further.
• Public key authentication works better with centralised onboarding, rotation, and revocation processes.
• For privileged access, keys can be tied to short-lived certificates or just-in-time workflows instead of being left static on disk.

Current guidance from identity and control frameworks generally favours strong authentication and reduced reliance on shared secrets. That aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls and with the operational discipline described in the same NHIMG research on NHIs, especially where service accounts and automation use SSH as a durable access path. The practical rule is to treat public key auth as the baseline for administrative SSH, then layer on least privilege, logging, and key lifecycle management.

These controls tend to break down in large fleet environments where keys are copied manually, ownership is unclear, and revocation cannot keep pace with server sprawl.

Common Variations and Edge Cases

Tighter SSH control often increases administrative overhead, so organisations have to balance ease of access against credential resilience. That tradeoff is real when teams support legacy systems, break-glass accounts, or vendor access paths that were designed around passwords.

Best practice is evolving around a few common exceptions. Password authentication may still appear in recovery workflows, initial bootstrapping, or constrained environments where key distribution is not yet operationally mature. Even then, it should be time-bound and monitored. Public key authentication is not automatically safe on its own either: unmanaged keys can become long-lived secrets, and a stolen private key can be just as damaging as a stolen password if there is no passphrase, hardware protection, or revocation discipline.

For organisations that need stronger assurance, current guidance suggests combining key-based SSH with certificate authorities, short-lived credentials, and central inventory of who or what can authenticate. That is especially important for service accounts and automation jobs, where the real issue is not user convenience but the identity lifecycle. Passwords can be acceptable for narrow fallback cases, but they are a poor default for persistent administrative access, especially where public key management is already feasible.

Where environments span unmanaged endpoints, shared admin jump hosts, or outsourced operations, the model breaks down because private key custody and revocation become hard to prove and harder to enforce.

Related resources from NHI Mgmt Group

• What is the difference between NTLM and Kerberos for enterprise authentication?
• What is the difference between authentication and authorization in chatbot security?
• What is the difference between knowledge-based authentication and inherence-based authentication in MFA?
• What is the difference between passwordless authentication and simply hiding the password?