The client checks the permissions of private key files and aborts with 'WARNING: UNPROTECTED PRIVATE KEY FILE!' followed by 'Permissions 0644 for id_ed25519 are too open' and then falls through to another authentication method, usually ending in 'Permission denied (publickey)'. The key must be readable only by its owner, mode 0600, and the ~/.ssh directory should be 0700.
This bites when keys are restored from an archive, copied out of a Docker build context, or written by a CI step that does not set a umask. A tar extraction as root preserves the archive's modes, which may be wrong.
Fix with 'chmod 600 ~/.ssh/id_ed25519' and 'chmod 700 ~/.ssh'. On a filesystem without POSIX permissions, such as a mount from Windows or a bind mount with a fixed mode, no chmod will help; copy the key to a real filesystem first, or pass it through ssh-add from a pipe so it never lands on disk. The 'StrictModes' option on the server side applies the same reasoning to authorized_keys, which is the usual cause of a server ignoring a key that looks correctly installed.