WARNING: UNPROTECTED PRIVATE KEY FILE! with Permissions 0644 for '/root/.ssh/id_ed25519' are too open. means the SSH client refused to use your private key because other users on the machine can read it. Run chmod 600 on the key file and connect again.

The key itself is fine. Only its file mode is wrong, and once the file is readable by its owner alone, the same key logs in.

The error

$ ls -l /root/.ssh/id_ed25519
-rw-r--r-- 1 root root 399 Nov 13 05:22 /root/.ssh/id_ed25519
exit=0
$ ssh -o BatchMode=yes dev@sshd hostname
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/root/.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 "/root/.ssh/id_ed25519": bad permissions
dev@sshd: Permission denied (publickey,password).
exit=255

Why it happens

The key was created with ssh-keygen, and then changed with chmod 644 to stand in for a key that lost its mode on the way to this machine. A separate test key made with ssh-keygen -t ed25519 -N '' -f /root/modetest -q showed -rw------- (600). Mode 644 lets every user on the machine read the file. The client printed the warning, said This private key will be ignored, and carried on without it.

That is why the last line is Permission denied (publickey,password): the key that the server would have accepted was not used to log in, and with BatchMode=yes the client asked for no password either. With -v, the client still printed Offering public key for this key, then Load key ... bad permissions and No more authentication methods to try. If you only see that last line in a script's log, scroll up for the warning.

The fix

$ chmod 600 /root/.ssh/id_ed25519
exit=0
$ ls -l /root/.ssh/id_ed25519
-rw------- 1 root root 399 Nov 13 05:22 /root/.ssh/id_ed25519
exit=0
$ ssh -o BatchMode=yes dev@sshd hostname
eed60eb6a2a1
exit=0

After chmod 600 the owner can read and write the key and nobody else can. The same command then logged in and printed the server's host name (the container id). The key was not regenerated and nothing changed on the server. Other modes such as 640 or 400 were not tried here; 600 is the mode ssh-keygen gave the file in the first place.

How it was reproduced

Reproduced inside ubuntu:24.04 containers on Docker engine 29.9.3, with OpenSSH_9.6p1 Ubuntu-3ubuntu13.20 on both sides (apt-get install -y openssh-client openssh-server). The client ran as root with an Ed25519 key made by ssh-keygen -t ed25519 -N '' -C dev-client -f /root/.ssh/id_ed25519; the server was a second container on the same Docker network with a test user dev whose authorized_keys held the public half. The containers were removed afterwards.

Frequently asked

How do I fix Permissions 0644 are too open for an SSH key?
Run chmod 600 on the private key file so only its owner can read it, then connect again. In this test the same key logged in right after the change.
Why does SSH say This private key will be ignored?
The client refused a private key file that other users could read. It skipped the key and tried to log in without it, which ended in Permission denied.
Do I need a new SSH key after the UNPROTECTED PRIVATE KEY FILE warning?
Not for this warning. Here only the file mode was wrong, and the existing key worked after chmod 600. Whether the key should be replaced depends on whether someone else could have read it.

When the key is accepted locally but the server still says no, see Permission denied (publickey). More decoded errors in the Fixes category.