SSH refuses to connect when the ~/.ssh/known_hosts file has incorrect permissions or is owned by the wrong user. This is a security check SSH performs to prevent unauthorized file modifications from compromising your connections.
SSH is a security-conscious protocol that performs strict permission checks on configuration files before connecting to remote hosts. The known_hosts file stores the public keys of remote hosts you've previously connected to, allowing SSH to verify host identity and prevent man-in-the-middle attacks. SSH rejects this file if it's writable by anyone other than the owner, as this could allow an attacker to modify stored host keys and intercept your connections. Similarly, if the file is owned by a different user than the one running SSH, the current user cannot trust its contents.
First, see what the current state of the file is:
ls -la ~/.ssh/known_hostsOutput should look like: -rw------- 1 username groupname
The first part (-rw-------) shows permissions as 600, and the owner should be your username. If it shows a different user or different permissions, that's your problem.
If the file is owned by a different user, change it to your user:
sudo chown $USER:$USER ~/.ssh/known_hostsThis sets the file owner to your current user and group. If the ownership issue is widespread in your .ssh directory, fix all files at once:
sudo chown -R $USER:$USER ~/.sshThe -R flag applies the change recursively to all files and subdirectories.
Set the known_hosts file to the correct permissions (600 = read/write for owner only):
chmod 600 ~/.ssh/known_hostsIf you want to fix all SSH files at once with their proper permissions:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/known_hosts
chmod 600 ~/.ssh/config
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub
chmod 600 ~/.ssh/authorized_keysNote: Public keys (*.pub) use 644 (read-only for others), but private keys and config files use 600 (owner-only).
Test that SSH can now access known_hosts by attempting a connection to a previously visited host:
If you've never connected before, SSH will ask if you trust the host and then update known_hosts. If you still get the permission error, move to the next step.
SSH also checks permissions on your home directory. If your home directory is too permissive, SSH will reject all files within it:
ls -ld ~Should show: drwxr-xr-x (755 permissions) or more restrictive.
If home directory is writable by others (e.g., 777), SSH will refuse to trust ~/.ssh files:
chmod 755 ~This makes home directory readable/executable by others but not writable.
If you suspect the known_hosts file itself is corrupted or contains entries that are causing trust issues, you can safely remove and rebuild it:
rm ~/.ssh/known_hostsThe next time you connect to a host, SSH will recreate the file with correct permissions:
SSH will ask if you trust the host's fingerprint (verify this matches official documentation for that host if possible), then add the entry to known_hosts.
Advanced considerations:
SSH Agent and Permissions: If you use SSH agent (ssh-add), the agent works independently but will still respect the security checks on known_hosts. The agent stores passphrases in memory, but it doesn't bypass file permission validation.
SELinux and AppArmor: On systems with mandatory access controls, even if traditional file permissions are correct, security policies (SELinux contexts or AppArmor profiles) can restrict SSH file access. Check security policy logs if permission fixes don't work:
sudo ausearch -m apparmor | grep known_hosts
sudo ausearch -m selinux | grep known_hostsMacOS Specific: On macOS with new user migrations or system updates, file ownership can change unexpectedly. Also, macOS caches SSH key permissions in the Keychain, so fixes might require reconnecting with Keychain reset.
Container/VM Mounts: In Docker containers or VMs with mounted home directories, NFS/SMB mounts might not respect Unix permissions properly. Verify mount options with mount | grep home and consider remounting with proper permission flags.
Root-caused Permission Changes: If permissions keep reverting, check for cron jobs or scripts running as other users that might be regenerating .ssh files. Use sudo crontab -l and sudo systemctl list-timers to identify automation.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH
sign_and_send_pubkey: signing failed for RSA from agent: agent refused operation
How to fix "sign_and_send_pubkey: signing failed for RSA from agent: agent refused operation" in SSH