SSH passwordless login exposes the governance gap in key management

At a glance

What this is: This is a step-by-step tutorial on configuring SSH passwordless login, with a clear warning that key-based access still depends on rotation, permissions, and lifecycle control.

Why it matters: It matters because SSH keys are NHI credentials, and IAM teams need the same governance discipline for service access, server access, and human admin workflows.

👉 Read StrongDM's step-by-step guide to SSH passwordless login

Context

SSH passwordless login is still identity and access management, not just a convenience feature. It replaces a password prompt with key-based authentication, but the real governance question is who holds the private key, how it is protected, when it is rotated, and how it is revoked when access ends.

For infrastructure teams, that makes SSH a classic non-human identity problem. The article is useful because it shows how quickly unmanaged keys become operational debt across onboarding, offboarding, and audit, especially when access is distributed across servers and client devices.

Key questions

Q: What breaks when SSH keys are not managed like NHI credentials?

A: Access becomes persistent, difficult to review, and easy to overlook during offboarding. SSH keys can remain valid long after the original need for access has changed, which creates orphaned access and audit gaps. Treating SSH as NHI governance exposes the real control problem, which is lifecycle management rather than login mechanics.

Q: Why do SSH keys create governance issues in large environments?

A: Because every server can maintain its own trust list, manual key distribution quickly produces inconsistency. When keys are added, copied, or removed by hand, the organisation loses confidence that the approved access set matches reality. That mismatch is a lifecycle and visibility problem, not just an authentication problem.

Q: How do teams know if SSH passwordless access is actually under control?

A: They should be able to answer who owns each key, where it is stored, which servers trust it, and when it was last rotated or removed. If those answers require searching individual systems, the programme lacks central governance. The strongest signal is whether revocation can happen quickly and consistently.

Q: What is the difference between SSH key management and passwordless convenience?

A: Convenience is the user experience of avoiding repeated password entry, while key management is the governance of the private key lifecycle. A passwordless workflow can still be poorly controlled if keys are not protected, rotated, and revoked. The two are not the same, and security teams need to govern both.

Technical breakdown

SSH key pairs and server trust anchors

SSH passwordless login uses asymmetric cryptography. The client creates a private key and public key pair, then copies the public key to the server's authorized_keys file. During connection, the server challenges the client, and only possession of the private key proves access. The security model is stronger than shared passwords, but only if the private key remains protected and the server trusts the right public key. In practice, this turns SSH into a credential distribution and trust management problem as much as an authentication mechanism.

Practical implication: treat each SSH public key as a governed NHI credential tied to a specific server scope and owner.

SSH agent handling and passphrase protection

An SSH agent stores decrypted key material in memory so users do not re-enter a passphrase on every session. That improves usability, but it also shifts the risk boundary from authentication to endpoint security and session hygiene. A passphrase protects the private key at rest, while the agent reduces friction during use. The article's setup steps show why this matters: a key without a passphrase is immediately usable if stolen, and a mismanaged agent can extend that exposure across an entire workstation session.

Practical implication: require passphrases for private keys and review workstation controls around agent persistence and local key storage.

Authorized keys, permissions, and lifecycle governance

The server-side controls matter as much as the key itself. Authorized keys must be appended carefully, file permissions must be restrictive, and obsolete keys must be removed when users leave or roles change. This is where SSH becomes an identity lifecycle issue rather than a setup task. Manual distribution, revocation, and auditing do not scale well because every server holds a separate trust list. That creates drift between who should have access and which keys still work, especially in large estates with many administrators and automation accounts.

Practical implication: centralise key lifecycle governance so revocation, rotation, and access review are not left to individual server owners.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SSH passwordless login is an NHI governance problem, not a user convenience problem. The article correctly explains that public keys and private keys replace passwords, but the identity subject is still a non-human credential bound to infrastructure access. That means the real failure modes are key sprawl, stale trust, and weak offboarding, not whether a password prompt appears. Practitioners should read SSH through the same control lens used for service accounts and API keys.

Manual SSH key distribution creates lifecycle debt at the exact point where access should be most controlled. The article describes copying public keys server by server and appending them to authorized_keys, which is operationally workable but governance-light. Every manual exception increases the chance of orphaned access, especially when a user leaves, a device is replaced, or an administrator forgets to remove an old key. The implication is that the trust list itself becomes the asset that needs lifecycle management.

Ephemeral login convenience can hide standing credential exposure. SSH passwordless access reduces friction, but the private key remains a standing credential until it is rotated or revoked. That creates a persistent access window that does not naturally expire with a session, which is why SSH belongs in the same risk class as other long-lived NHI secrets. Practitioners should treat unused keys as active exposure, not dormant configuration.

File permissions are not a minor implementation detail. They are the enforcement boundary for private key custody. The article's chmod guidance shows that server and client controls both matter, because a key with weak local protection or permissive remote permissions undermines the whole access model. This is a classic example of how NHI governance depends on both credential stewardship and endpoint hardening. The lesson is to monitor the environment that stores the key, not just the server that accepts it.

SSH belongs in the same lifecycle framework as offboarding and recertification. The article notes that credentials must be destroyed as employees come and go, and that is the right governance frame. An SSH key that survives role change is functionally equivalent to any other stale NHI credential. The practitioner conclusion is straightforward: if a key can outlive the access reason, the programme has a lifecycle gap.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• Ultimate Guide to NHIs , Key Challenges and Risks is the right next read if you are mapping SSH keys into a broader NHI risk model.

What this signals

SSH passwordless access scales poorly without lifecycle automation. The operational story here is not whether keys work, but whether they can be governed at enterprise volume. When access is spread across servers, endpoints, and automation accounts, the control plane has to know which keys exist, which ones are active, and which ones should already be gone.

Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs, and SSH keys often disappear into the same visibility gap. That is why key inventories and revocation workflows should be treated as core identity controls, not infrastructure chores.

For practitioners

• Inventory all SSH keys as governed NHI credentials Map which users, servers, and automation processes hold private keys or authorized_keys entries, then assign an owner and business purpose to each credential.
• Enforce passphrases for private keys Require passphrase-protected keys for interactive admin access and document any exceptions for automation separately, with compensating controls and monitoring.
• Review server-side key permissions and cleanup Standardise restrictive permissions on .ssh and authorized_keys, then remove obsolete entries during role changes, offboarding, and device replacement.
• Centralise key rotation and revocation Move away from per-server manual key distribution where possible so rotation and revocation can be executed consistently across the estate.
• Separate human admin access from scripted automation Use distinct keys and distinct lifecycle rules for people and automation so an automation key is not treated as a personal login credential.

Key takeaways

• SSH passwordless login reduces friction, but it does not remove identity governance requirements around private keys, server trust, and offboarding.
• Manual key distribution and removal create the same lifecycle debt that plagues other NHI credentials, especially when access is shared across many servers.
• The practical control objective is not password removal alone, but central visibility into key ownership, rotation, and revocation.

Key terms

• SSH Key Pair: An SSH key pair is a matched public and private key used to authenticate access without a password. The public key is stored on the server, while the private key stays with the user or automation client and must be protected as a governed credential.
• Authorized Keys: Authorized keys are the server-side records that list which public keys are allowed to authenticate. In identity governance terms, they are a trust inventory that must be reviewed, updated, and cleaned up when access changes, because stale entries become persistent access paths.
• SSH Agent: An SSH agent is a local process that holds decrypted keys in memory so users do not re-enter passphrases every session. It improves usability, but it also extends the trust boundary to the workstation, which means endpoint hygiene and session control matter.
• Key Lifecycle Governance: Key lifecycle governance is the discipline of tracking where a credential is issued, how long it is valid, where it is used, and when it is revoked. For SSH, it is the difference between a managed access pattern and a pile of forgotten keys that still work.

Deepen your knowledge

SSH key lifecycle governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are translating SSH administration into a broader NHI control model, the course is a useful starting point.

This post draws on content published by StrongDM: How to Set Up SSH Passwordless Login (Step-by-Step Tutorial). Read the original.