SSH Authorized Keys

What SSH authorized keys do

SSH authorized keys are a trust list for passwordless SSH access. Each entry lets the server match a presented public key to the corresponding private key, so the account can log in without sharing or typing a password.

That makes authorized_keys a control point, not just a convenience feature. If the file is edited, copied, or left behind after a role changes, the account can still be accessed later by anyone who holds the matching private key.

Why SSH authorized keys matter for automation

Authorized keys are widely used for server administration, deployment jobs, backup jobs, and other non-interactive workflows because they let systems authenticate without a human present. In practice, they often carry more operational reach than a normal user login because they are reused across scripts, jump hosts, and automation tooling.

That convenience is also why they deserve explicit ownership and review. When teams treat an authorized key as a one-time setup detail, they can lose track of which systems still trust it, which account it belongs to, and whether the key is still needed.

NHIMG’s SSH Key and SSH Certificate Management Guide covers the governance side of that problem, including key sprawl, orphaned keys, bastions, and rotation.

How authorized keys become a security boundary

Because the server decides whether a key is trusted, authorized keys act as an access boundary for the target account. The security model depends on the strength of the private key, the protection of the account that stores the authorized_keys file, and the scope of what that account can reach after login.

That boundary can be stronger than passwords when keys are protected well, but it can also become persistent access if keys are copied broadly, shared across environments, or never removed. The risk is not only theft of the private key, but also stale trust that survives after a contractor leaves, a host is rebuilt, or a service is retired.

NHIMG’s NHI Lifecycle Management Guide is useful here because SSH keys are often part of broader machine access lifecycle management, including provisioning, rotation, and offboarding.

Operational patterns and common failure modes

Authorized keys usually fail in predictable ways: overly broad reuse, unmanaged distribution, lack of rotation, and placement on accounts with more privilege than the workflow needs. A single key on an admin account can silently outlive the job or service that introduced it.

Another common issue is that teams confuse authentication with authorisation. A key proves possession, but it does not by itself define what the account may do after login. If the shell, sudo rights, or attached group membership are too broad, the key becomes a high-impact entry path.

NHIMG’s Authorisation Models Guide helps place SSH access inside the wider access-control decision, especially where privileged shell access is involved.

Practitioner Guidance

Why practitioners should care: Treat authorized keys as governed credentials, not static config. Each key should have an owner, a purpose, and a removal path so access can be reviewed when systems, teams, or jobs change.

What to watch for: Look for shared keys, keys on dormant accounts, keys copied into images or automation repositories, and keys that grant access to privileged accounts without a clear business need. Those are the patterns that usually turn a simple login mechanism into persistent access.

For more on the wider control set, NHIMG’s IAM and IGA Basics provides the surrounding governance model for access review, entitlement ownership, and lifecycle control.

Related resources from NHI Mgmt Group

• What is the difference between controlling SSH access with PAM and controlling it with authorized keys on the destination host?
• How should security teams manage SSH authorized keys to prevent persistent unauthorized access?
• What breaks when unauthorized SSH keys are left in authorized_keys?
• How do attackers use SSH Authorized Keys?