If macOS Terminal reports “UNPROTECTED PRIVATE KEY FILE” or says your SSH key is too accessible, restrict access to the private key and check the .ssh directory. Open Terminal and run chmod 600 on the key file you actually use. This makes it readable and writable by your account only; SSH ignores private key files that other users can access. OpenBSD ssh(1) manual

Fix the private key’s permissions

First identify the key file. SSH’s common default private key names include id_ed25519 and id_rsa, but you may have another name or location. The .pub suffix identifies a public key; do not apply this fix to that file instead of the private key.

For a default Ed25519 key, enter:

chmod 600 "$HOME/.ssh/id_ed25519"

For another key, replace id_ed25519 with its actual filename. Quoting the path keeps spaces and other shell characters in the filename from being treated as syntax. If the key is somewhere else, use its full path inside the quotes. 600 grants read and write access to the owner and removes access for group and other users. OpenBSD chmod(1) manual

You can inspect the resulting mode with ls -l "$HOME/.ssh/id_ed25519". A typical display begins -rw-------; the first three permission characters after the file type show owner access, and the remaining groups show no access for group or others. The file owner must also be your account. If it belongs to another user, chmod may fail or the SSH client may still be unable to use it. Check ownership with ls -l; avoid changing ownership blindly, especially with sudo, because the correct fix depends on why the file belongs to someone else.

Check the .ssh directory

The SSH manual recommends that ~/.ssh/ be readable, writable, and searchable by its owner, and inaccessible to others. If SSH reports a permissions problem for the directory itself, run:

chmod 700 "$HOME/.ssh"

This removes group and other access while allowing your account full directory access. If the key is stored in a different folder, check each directory in its path: the account needs search (execute) permission to reach the file. Do not recursively run chmod across your whole home directory or .ssh folder as a first fix; that can change permissions on unrelated files with different needs. OpenBSD ssh(1) manual

Confirm SSH is using that key

A corrected key can still appear not to work if SSH is looking elsewhere or offering a different identity. Use -i to specify a key for one connection. Replace the example account and host with your own:

ssh -i "$HOME/.ssh/id_ed25519" user@example.com

The -i option selects the identity file used for public-key authentication. OpenBSD ssh(1) manual For a more detailed connection log, add -v:

ssh -v -i "$HOME/.ssh/id_ed25519" user@example.com

If you manage several hosts, you can set IdentityFile in ~/.ssh/config; the Host block determines which connection settings apply. The client may also try keys supplied by ssh-agent. IdentitiesOnly yes can limit identities offered to the configured identity files when an agent has many keys loaded. OpenBSD ssh_config(5) manual

Know when the error is elsewhere

A local private-key permission warning is different from Permission denied (publickey). The latter can mean the server does not recognize the matching public key, the username is wrong, or SSH is trying another identity. The public key corresponding to your private key must be authorized for the account on the remote host; changing local permissions does not install that public key on the server. OpenBSD ssh(1) manual

If chmod returns “Operation not permitted,” check whether you own the file and whether the path points to the key you intended. Avoid making a private key broadly readable to silence the warning: SSH’s restriction protects the credential, and removing it can cause the client to reject the key. Once the private key and its directory have suitable permissions, retry with -v and follow the diagnostic output to distinguish a local file issue from an authentication or server-side problem.

Sources