The problem
SSH refuses a private key with an “unprotected private key file” warning. The key may be valid; the client is rejecting permissions that allow other users to read it.
Inspect before changing
Check both the key and its parent directory. Ownership matters as much as the numeric mode.
ls -ld ~/.ssh
ls -l ~/.ssh/id_ed25519
stat ~/.ssh/id_ed25519A typical correction
On a personal Linux account, the usual intent is that only the owner can traverse the directory or read the private key.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519Verify the result
Use verbose output to see which key the client actually offers:
ssh -v user@example.internalLook for the resolved identity file and stop once the client moves beyond the permission error. A different failure after that point is a new problem, not proof that the mode change failed.
Why it works
Private-key authentication depends on the key remaining private. OpenSSH treats overly broad permissions as a security failure instead of trusting a file that another local user could replace or read.
Related checks
- Confirm the file belongs to the expected user.
- Check whether a config entry points at a different key.
- Treat keys copied from Windows or a network share with extra care.