authorized_keys
The file listing which public keys are allowed to log in to a given account over SSH. If this file is writable by anyone other than its owner, an attacker who gains any foothold can add their own key and keep access even after the original vulnerability is fixed.
Why file permissions matter here
SSH silently refuses to use an authorized_keys file, or the .ssh directory containing it, if the permissions are too open. This is a deliberate safeguard against a misconfigured server letting any local user add themselves a backdoor key.
A common source of leftover access
Old keys accumulate in this file over time, for former employees, decommissioned automation scripts, or contractors whose engagement ended months ago. Nobody notices until an audit or an incident specifically goes looking.
Frequently asked questions
What permissions should this file and its directory have?
The .ssh directory should be 700 and authorized_keys should be 600, both owned by the account they belong to.
Can one file list multiple keys?
Yes. Each line is a separate authorized key, so a single account can allow several people or devices to log in independently.
How often should this file be reviewed?
At minimum whenever someone leaves the team or a service is decommissioned, and ideally as part of a routine periodic access review.
Want to see where your own server stands?
Run the free, read-only server check, or open the Security Lab and watch the detect, contain, recover, verify loop in action.
Get your free server checkOpen the Security Lab