git authentication_error ai_generated true

Permissions 0644 for '/home/user/.ssh/id_rsa' are too open — SSH refuses key with wrong permissions

ID: git/ssh-key-permission

Also available as: JSON · Markdown
97%Fix Rate
96%Confidence
110Evidence
2016-01-01First Seen

Version Compatibility

VersionStatusIntroducedDeprecatedNotes
2 active

Root Cause

SSH refuses to use private keys that are readable by other users. This is a security feature. The private key file must have permissions 600 (owner read/write only) and the .ssh directory must be 700 (owner only). This commonly happens when copying keys between systems, extracting from archives, or using shared filesystems.

generic

Workarounds

  1. 98% success Set correct permissions: chmod 600 for keys, chmod 700 for .ssh directory
    Run: 'chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_rsa && chmod 644 ~/.ssh/id_rsa.pub && chmod 644 ~/.ssh/known_hosts && chmod 600 ~/.ssh/config'. Private keys must be 600, public keys and known_hosts can be 644, the .ssh directory itself must be 700.

    Sources: https://man.openbsd.org/ssh

  2. 95% success Copy SSH keys to native Linux filesystem in WSL2
    Copy keys from Windows mount to native Linux path: 'cp /mnt/c/Users/<name>/.ssh/id_rsa ~/.ssh/id_rsa && chmod 600 ~/.ssh/id_rsa'. The native Linux filesystem supports proper permissions. Alternatively, set WSL mount options in /etc/wsl.conf: [automount] options = metadata,umask=077.
  3. 92% success Use SSH config to specify key path explicitly
    Add to ~/.ssh/config: 'Host github.com\n  IdentityFile ~/.ssh/github_key\n  IdentitiesOnly yes'. This ensures git uses the correct key with correct permissions. Useful when you have multiple keys for different services.

    Sources: https://man.openbsd.org/ssh_config

Dead Ends

Common approaches that don't work:

  1. Setting permissions to 644 or 666 on the private key file 99% fail

    SSH strictly requires private keys to be readable only by the owner (mode 600 or stricter). Permissions 644 means group and others can read the file, which SSH considers a security risk. It will refuse to use the key and fall back to password auth (which may also fail).

  2. Using chmod on SSH keys in a mounted Windows filesystem (WSL2, VirtualBox shared folders) 90% fail

    Windows filesystems (NTFS, FAT32) mounted in Linux don't support Unix file permissions. chmod appears to succeed but has no effect. The permissions remain whatever the mount options specify (typically 777 or 755). You must either copy keys to a native Linux filesystem or use mount options to set default permissions.

  3. Using ssh-add without fixing file permissions first 95% fail

    ssh-add also checks private key file permissions before adding the key to the agent. You'll get the same 'too open' error from ssh-add. The file permissions must be fixed first before any SSH tool will accept the key.

Error Chain

Frequently confused with: