How can security teams detect SSH authorised keys abuse?

What SSH authorised keys abuse looks like in practice

SSH authorised keys abuse is usually visible as a trust-path change, not a password event. The key signal is that an account starts accepting a new public key, or an existing key is reused in a way that does not match normal administration. The most useful detections focus on changes to authorized_keys, unexpected key-based logins, and source patterns that do not fit the account’s usual operators.

The detection problem is broader than “who logged in.” A key can be inserted through a stolen admin session, a compromised CI/CD pipeline, a misused deployment script, or direct filesystem access. For that reason, SSH key monitoring works best when it is paired with file-integrity monitoring, change management evidence, and authentication telemetry.

How to spot the change that matters

Start with the files and paths that grant SSH access. Monitor authorized_keys for additions, removals, and permission changes, then compare each change against an approved admin workflow. A new key is suspicious when it appears without a ticket, outside a maintenance window, from an unfamiliar host, or for an account that normally uses another access method. The same is true when a key is added to a shared account, a break-glass account, or an account that should not have direct shell access.

Detection improves when you baseline normal administration patterns for each account, not just the host. A developer account that normally connects from a jump host should not suddenly authenticate from a workstation or cloud IP range that has never been used before. Likewise, a service account that should never be used interactively becomes suspect if you see SSH logins tied to that identity.

It also helps to watch for weak control states around the key material itself. Changes to file ownership or permissions, unexpected changes in key comments, or edits that replace one trusted source with many keys can all indicate that access has been broadened quietly. The key question is whether the change expands access in a way that is explainable and attributable.

Why this abuse is hard to catch

SSH keys are attractive to attackers because they can provide durable access without triggering password resets or MFA prompts. Once an attacker plants a key, they can return repeatedly until the key is removed, and they may blend in with legitimate automation if the environment already uses scripted SSH access. That makes the abuse easy to miss when teams only watch for failed logins or password-based compromise.

For that reason, the best detections combine host telemetry and authentication evidence. A key change on disk is important, but it becomes much stronger when it is followed by an SSH session from a new source address, an unusual time of day, or a host that does not normally administer the target system. Where possible, correlate shell access with the change record and the identity of the operator who approved the change.

How to separate legitimate automation from abuse

Legitimate SSH use often has consistent patterns: the same deployment hosts, the same accounts, and predictable timing. Abuse tends to break those patterns. If a key appears for an account that has no documented need for SSH, if an existing automation key starts being used from a different network segment, or if the account begins authenticating to systems outside its normal scope, treat the event as a potential intrusion path rather than a simple configuration change.

When possible, track key inventory at the account level and the origin level. That means knowing which keys exist, where they came from, why they exist, and which systems they can reach. A key without ownership, expiration, or a documented business purpose is a standing access risk, even if no obvious abuse has been confirmed yet.

Risk and Threat Considerations

SSH key abuse creates durable, low-noise persistence because the attacker can authenticate as a trusted user or service without repeatedly stealing a password. The same technique can support lateral movement, privilege escalation, and quiet re-entry after defenders believe the initial compromise is closed.

Failure mechanism: The attacker adds or reuses a trusted public key, or weakens the file controls around authorized_keys, so SSH accepts the session as legitimate and the activity blends into normal administrative traffic.

Impact: Defenders may miss the access path entirely, allowing sustained shell access, hidden administration, data theft, or further host compromise until the key is discovered and removed.

Practitioner Guidance

What to verify: Confirm that every key change maps to an approved change record, an identified owner, and a system that is supposed to accept SSH key-based access. If you cannot tie the key to a person, automation path, or service account with a valid purpose, treat it as suspicious.

Decision rule: If an added key grants access to a production host or privileged account, prioritise removal or rotation of that access path before spending time on attribution. If the key is part of a known automation flow, verify the source host, destination scope, and command restrictions before accepting it as benign.

Practitioner takeaway: The most reliable detections are the ones that connect file change, identity, and network source into one event story, because SSH key abuse is usually an access-path problem long before it becomes a visible incident.

Related resources from NHI Mgmt Group

• Guide: SSH Key and SSH Certificate Management Guide
• Why is the abuse of NHIs a priority for security teams?
• How should security teams detect cloud account abuse when attackers use valid AWS access keys to create persistence?
• How should security teams detect SNS abuse when long-lived AWS access keys are exposed?
• How can security teams detect registry run keys and startup folder abuse?