How to fix Bad owner or permissions on /home/user/.ssh/known_hosts in SSH

SSHBEGINNERHIGHUpdated Jan 4, 2026· 185 views

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.

Quick fix

Fixes Bad owner or permissions on /home/user/.ssh/known_hosts

ls -la ~/.ssh/known_hosts
  1. Check current known_hosts file ownership and permissions
  2. Fix file ownership
  3. Fix file permissions
  4. Verify the fix works
ssh — error
ls -la ~/.ssh/known_hosts
Bad owner or permissions on /home/user/.ssh/known_hosts

What this error means

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.

Typical symptoms

  • SSH connection fails with "Bad owner or permissions" error before attempting authentication
  • Cannot connect to any remote host; all SSH commands fail immediately
  • Error appears even with verbose SSH output (-v flag) at the beginning of the connection attempt
  • Manual SSH commands fail but Git operations may work if they use SSH key agent
  • The known_hosts file path is shown in the error message

Common causes

  1. The known_hosts file is owned by a different user than the current user trying to connect
  2. File permissions are too permissive (e.g., 777, 666, or 644 when 600 is expected)
  3. The .ssh directory itself has incorrect permissions (should be 700)
  4. File ownership was changed by system administration or file operations (sudo, chown, cp -r)
  5. Known_hosts file was copied from another user's account without changing ownership
  6. Home directory has incorrect permissions (writable by others), causing SSH to distrust all files within

How to fix "Bad owner or permissions on /home/user/.ssh/known_hosts"

1Check current known_hosts file ownership and permissions

First, see what the current state of the file is:

bash
ls -la ~/.ssh/known_hosts

Output 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.

2Fix file ownership

If the file is owned by a different user, change it to your user:

bash
sudo chown $USER:$USER ~/.ssh/known_hosts

This 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:

bash
sudo chown -R $USER:$USER ~/.ssh

The -R flag applies the change recursively to all files and subdirectories.

3Fix file permissions

Set the known_hosts file to the correct permissions (600 = read/write for owner only):

bash
chmod 600 ~/.ssh/known_hosts

If you want to fix all SSH files at once with their proper permissions:

bash
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_keys

Note: Public keys (*.pub) use 644 (read-only for others), but private keys and config files use 600 (owner-only).

4Verify the fix works

Test that SSH can now access known_hosts by attempting a connection to a previously visited host:

bash
ssh user@example.com

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.

5Check parent directory permissions

SSH also checks permissions on your home directory. If your home directory is too permissive, SSH will reject all files within it:

bash
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:

bash
chmod 755 ~

This makes home directory readable/executable by others but not writable.

6Regenerate known_hosts if corruption is suspected

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:

bash
rm ~/.ssh/known_hosts

The next time you connect to a host, SSH will recreate the file with correct permissions:

bash
ssh user@example.com

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 notes

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:

bash
sudo ausearch -m apparmor | grep known_hosts
sudo ausearch -m selinux | grep known_hosts

MacOS 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.

Frequently asked questions

What does "Bad owner or permissions on /home/user/.ssh/known_hosts" mean?
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.
How do I fix "Bad owner or permissions on /home/user/.ssh/known_hosts"?
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.
What causes "Bad owner or permissions on /home/user/.ssh/known_hosts"?
The known_hosts file is owned by a different user than the current user trying to connect File permissions are too permissive (e.g., 777, 666, or 644 when 600 is expected) The .ssh directory itself has incorrect permissions (should be 700)
Is the "Bad owner or permissions on /home/user/.ssh/known_hosts" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading