Why does SSH reject my private key because of permissions?
The client may refuse a private key when other users can read it or ownership is unsuitable. This is a local file-protection issue, so changing the server’s password policy or authorized_keys file will not resolve that specific warning.
Instructions
1. Confirm the file SSH is actually using
Inspect the affected host’s identity setting before changing permissions on a similarly named file.
ssh -G example-server | Select-String -Pattern "^identityfile "The effective identity paths tell you which local files are candidates for this connection.
2. Inspect the exact private-key ACL
Read permissions without exposing the file’s content.
icacls.exe "$env:USERPROFILE\.ssh\server_ed25519"
(Get-Acl -LiteralPath "$env:USERPROFILE\.ssh\server_ed25519").OwnerReview owner, inherited access and explicit grants. Use the actual affected private-key path.
3. Correct only inappropriate access
Follow the file-owner policy to remove unintended read access while retaining the intended user and required trusted system principals. Then retry using that explicit key. Do not grant broad read access, change an entire drive ACL, or use a shared folder as a shortcut.
Check the result
- The private-key owner and ACL meet the client’s requirements.
- The explicit SSH connection no longer reports unsafe key-file permissions.
Troubleshooting
- The key is on a shared or unusual filesystem
- Move through an authorised secure workflow to a location with supported per-file access controls, or use an approved credential store.
- The warning refers to a Linux file
- Use Linux ownership and mode checks for that environment instead of Windows icacls.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.