This error occurs when your SSH private key has overly permissive file permissions. SSH refuses to use the key for security reasons, requiring file access restricted to your user only to prevent unauthorized access to your private key.
SSH requires private keys to remain confidential and accessible only to their owner. When SSH detects that a private key file has permissions that allow other users or groups to read it (such as 0644, 0755, or 0777), it rejects the key with a "bad permissions" error. This is a critical security check enforced by OpenSSH. If your private key is readable by others, someone could steal it and use it to access your accounts, servers, or repositories without your knowledge or consent. SSH will warn you about unprotected files and refuse to use them, forcing you to fix the permissions before authentication can proceed. The error message often comes with a warning: "WARNING: UNPROTECTED PRIVATE KEY FILE! Permissions X are too open. It is required that your private key files are NOT accessible by others."
First, verify the current permissions on your private key file:
ls -la ~/.ssh/id_rsaLook for the permission string at the start (e.g., -rw-r--r--). The format is -rw-r--r-- where:
- First character is file type (- for regular file)
- Next 3 chars are owner permissions (rw- = read, write, no execute)
- Next 3 chars are group permissions (r-- = read only)
- Last 3 chars are other/world permissions (r-- = read only)
The numeric equivalent is 0644. If it shows anything other than -rw------- (0600) or -r-------- (0400), the permissions are too open and need fixing.
Change the private key permissions to 0600 (read and write for owner only):
chmod 600 ~/.ssh/id_rsaAlternatively, use 0400 for a more restrictive read-only approach:
chmod 400 ~/.ssh/id_rsaBoth 0600 and 0400 are valid and will make SSH happy:
- 0600 (-rw-------): Owner can read and write. Allows you to modify or delete the key.
- 0400 (-r--------): Owner can read only. Maximum security - prevents accidental modification.
Most users prefer 0600 for flexibility.
Ensure your .ssh directory has secure permissions:
chmod 700 ~/.sshThe .ssh directory must be readable, writable, and executable only by you (0700). This restricts access to all private keys and configuration files within the directory.
SSH will also complain if the .ssh directory is too permissive:
# Bad - world can read
drwxr-xr-x 2 user user 4096 ~/.ssh
# Good - only owner can access
drwx------ 2 user user 4096 ~/.sshSet correct permissions for all files in your .ssh directory:
# Fix all private keys and sensitive files
chmod 600 ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_ed25519
chmod 600 ~/.ssh/id_ecdsa
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/known_hosts
chmod 600 ~/.ssh/config
# Public keys can be readable by others
chmod 644 ~/.ssh/id_rsa.pub
chmod 644 ~/.ssh/id_ed25519.pub
chmod 644 ~/.ssh/id_ecdsa.pubKey permissions guide:
- Private keys (id_rsa, id_ed25519, etc.): 0600
- Public keys (*.pub): 0644
- authorized_keys, known_hosts, config: 0600
- .ssh directory: 0700
Ensure all SSH files are owned by your user, not root or another user:
# Check ownership
ls -la ~/.ssh/
# Fix if necessary
sudo chown -R $USER:$USER ~/.sshIf your SSH files are owned by a different user or root, SSH will refuse to use them regardless of file permissions. This is a security feature to prevent privilege escalation attacks.
The output should show your username in both owner and group columns:
-rw------- user user id_rsa
-rw-r--r-- user user id_rsa.pub
drwx------ user user .sshAfter fixing permissions, test your SSH connection:
# Test with verbose output to see what's happening
ssh -v user@remote-host
# Or test with a GitHub connection
ssh -T [email protected]The -v flag shows verbose output. You should no longer see the "bad permissions" warning, and SSH should use your private key for authentication.
If it still fails, verify permissions one more time:
# Check permissions again
ls -la ~/.ssh/
stat ~/.ssh/id_rsa
# Check SSH debug to see which key is being used
ssh -vvv user@remote-host 2>&1 | grep -i "identity\|permission\|bad"If you have multiple keys or want to fix everything at once, use this comprehensive command:
# Fix ownership and all permissions at once
sudo chown -R `whoami`:`whoami` ~/.ssh && \
chmod 700 ~/.ssh && \
chmod 600 ~/.ssh/id_* && \
chmod 644 ~/.ssh/*.pub && \
chmod 600 ~/.ssh/authorized_keys 2>/dev/null && \
chmod 600 ~/.ssh/known_hosts 2>/dev/null && \
chmod 600 ~/.ssh/config 2>/dev/null
# Verify it worked
ls -la ~/.ssh/This one-liner:
1. Changes ownership of all files to your user
2. Sets .ssh directory to 0700
3. Sets all private keys to 0600
4. Sets all public keys to 0644
5. Sets other files to 0600
6. Suppresses errors for files that don't exist (2>/dev/null)
Windows SSH Key Permissions: If you're using SSH on Windows with tools like Git Bash, PuTTY, or Windows Subsystem for Linux (WSL), the permission model differs from Linux.
For WSL (Windows Subsystem for Linux), use the standard Linux chmod commands above.
For native Windows SSH or PuTTY, you must use Windows file properties instead:
1. Right-click the .pem or .ppk file
2. Select Properties
3. Go to Security tab
4. Click Advanced
5. Click "Disable inheritance"
6. Remove all inherited permissions
7. Grant only your user account "Full Control"
8. Click Apply
Umask and preventing this in the future: If you frequently encounter permission issues when generating new keys, configure your umask:
# Check current umask
umask
# Set umask to create files with 0600 by default
umask 077
# Make it permanent in ~/.bashrc or ~/.zshrc
echo "umask 077" >> ~/.bashrcA umask of 0077 ensures new files are created with 0600 permissions by default, preventing this problem entirely.
SELinux systems: On SELinux-enabled systems (RHEL, CentOS, Fedora), you may also need to check SELinux contexts:
# Check SELinux context
ls -lZ ~/.ssh/
# Reset to correct context if needed
restorecon -r ~/.sshSSH agent and key permissions: If you're using ssh-agent, it may also refuse to load keys with bad permissions:
# Clear and reload ssh-agent
eval "$(ssh-agent -k)"
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsaLoad key "/home/user/.ssh/id_rsa": invalid format
How to fix 'Load key invalid format' in SSH
Bad owner or permissions on /home/user/.ssh/config
How to fix "Bad owner or permissions on .ssh/config" in SSH
Error connecting to agent: Connection refused
How to fix "Error connecting to agent: Connection refused" in SSH
Connection closed by UNKNOWN port 65535
How to fix 'Connection closed by UNKNOWN port 65535' in SSH
Offending ECDSA key in /home/user/.ssh/known_hosts:line
How to fix "Offending ECDSA key in known_hosts" in SSH