The message
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/user/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/user/.ssh/id_ed25519": bad permissions
user@server: Permission denied (publickey,password).Despite the word "warning", this stops the key from being used. The check is on your own computer, before the private key is used to sign anything. The server has not refused you.
The fix
chmod 600 ~/.ssh/id_ed25519Use the path shown in the message. Mode 600 means only you can read and write. Mode 400, read only, is also accepted. Any permission for group or others is refused: we tried 640, 660, 644 and 440, and all four gave this error.
To check without connecting, use one of these:
ls -l ~/.ssh/id_ed25519
ssh-keygen -y -f ~/.ssh/id_ed25519The second command prints the public key if the permissions are fine, and the same warning if they are not. If the key has a passphrase, it asks for it first.
To tidy a whole folder:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_*
chmod 644 ~/.ssh/*.pubPublic keys can stay readable, which is why the last line restores them.
How a key gets these permissions
- It was copied from a USB stick, a shared folder or a zip file, or downloaded from a browser.
- A script or a backup restore wrote it with the default mode.
- Someone ran
chmod -R 755on the home directory.
If you cannot tell where a copied key has been, it is simpler to generate a new Ed25519 SSH key and replace the old one on your servers.
Related cases on your computer
The key is owned by someone else
A key created with sudo belongs to root. With mode 600 you cannot read it at all, and the message is different:
Load key "/home/user/.ssh/id_ed25519": Permission deniedTake it back with sudo chown "$USER" ~/.ssh/id_ed25519.
No warning, only Permission denied
If a .pub file sits next to the key, ssh first offers the public half and reads the private file only when the server accepts it. So with a wrong key you never see this warning, even with bad permissions. ssh -v shows the order:
debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:...
debug1: Server accepts key: /home/user/.ssh/id_ed25519 ED25519 SHA256:...
Permissions 0644 for '/home/user/.ssh/id_ed25519' are too open.The config file
The same kind of check applies to your client configuration:
Bad owner or permissions on /home/user/.ssh/configFix it with chmod 600 ~/.ssh/config.
Windows
OpenSSH on Windows uses file access lists, not chmod. These PowerShell commands come from the AWS documentation, with your key path in $path:
icacls.exe $path /reset
icacls.exe $path /GRANT:R "$($env:USERNAME):(R)"
icacls.exe $path /inheritance:rIn WSL, a key under /mnt/c may not keep Linux permissions. Copy it to ~/.ssh inside the Linux file system and run chmod 600 there.
The same problem on the server: StrictModes
The server has a similar check, but you do not see a warning. The client prints only Permission denied (publickey,password). and the reason is in the server log, which you need another way in to read, such as a console:
Authentication refused: bad ownership or modes for directory /home/user/.sshOn Debian and Ubuntu use sudo journalctl -u ssh, and on most other systems journalctl -u sshd. This is what we saw on OpenSSH 10.0 from Debian 13, with StrictModes yes, the default:
| Change | Result |
|---|---|
Home directory 777 | Refused, bad ownership or modes for directory |
~/.ssh group writable, group is root | Refused, same message |
authorized_keys group writable, group is root | Refused, bad ownership or modes for file |
authorized_keys owned by root, mode 600 | Refused, Could not open user 'user' authorized keys |
authorized_keys mode 644 | Login works |
~/.ssh mode 755 | Login works |
The Debian build also allowed group write when the group was the user's own private group, so do not expect the same on every system. The safe setting is the same everywhere. Run this as the user on the server:
chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$USER" ~/.sshIf you run the last line through sudo, name the user instead of $USER.
Do not set StrictModes no. It does make the login work, as we confirmed, but it also accepts an authorized_keys file that other users may have been able to change. To see the current value:
sudo sshd -T | grep -i strictmodesIf the modes are right and the key is still refused, see Permission denied (publickey).
Questions
What permissions should an SSH private key have?
600, so only you can read and write it. 400, read only, also works. Any access for group or others makes ssh ignore the key.
What permissions should ~/.ssh and authorized_keys have?
700 for ~/.ssh and 600 for authorized_keys. Public keys ending in .pub can stay at 644.
Can I turn off the permission check?
Not on the client. On the server, StrictModes no skips its own check, but it also accepts an authorized_keys file that others could have changed, so fix the modes instead.
Sources
- ssh(1), OpenBSD manual
- sshd_config(5), StrictModes
- Troubleshoot connecting to an EC2 Linux instance, AWS