Fix SSH "Permissions Too Open" Error on Windows 11

Quick Fix: Run two PowerShell commands and you’re done. Takes 30 seconds. Full explanation below.

You’re about to push code to GitHub. You generate a fresh SSH key, try to add it to ssh-agent, but it doesn’t work. You get an error instead:

Permissions for 'C:/Users/YourName/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

Here’s the thing: this isn’t a bug. It’s SSH protecting you. But the fix is simple, and once you understand it, you’ll never struggle with this again.

🔑 The 30-Second Fix

Open PowerShell as Administrator and run:

cd ~/.ssh
icacls .\id_ed25519 /inheritance:r
icacls .\id_ed25519 /grant:r "%username%:F"

Done. Your SSH key now works.

Want to understand what just happened? Keep reading. Want to automate this for future keys? Skip to the “Never Deal With This Again” section.

Why This Happens (The 2-Minute Explanation)

Think of SSH keys as passwords to your servers and repositories. Would you leave your passwords in a shared folder where your roommate could read them? Of course not.

Windows uses something called Access Control Lists (ACLs) for file permissions. When you create a new file, it often inherits permissions from its parent folder. Your .ssh folder might say “sure, let other user accounts see what’s inside.”

SSH sees this and refuses to play along. It’s protecting you.

On Linux or Mac, this is simpler — files either have the right permissions or they don’t. Windows is more granular, which is powerful but can be confusing.

The Step-by-Step Fix

Let me walk you through this properly. Even if you used the quick fix above, this section shows you exactly what’s happening.

Step 1: Open PowerShell as Administrator

• Press Win + X
• Select “Windows PowerShell (Admin)” or “Terminal (Admin)”
• Click “Yes” on the User Account Control prompt

Step 2: Navigate to Your SSH Folder

cd ~/.ssh

This command takes you to your SSH directory where your keys are stored (typically C:\Users\YourUsername\.ssh).

Step 3: Fix the Permissions

Run these two commands on your private key file:

# Remove inherited permissions
icacls .\id_ed25519 /inheritance:r
# Grant only your user account full control
icacls .\id_ed25519 /grant:r "%username%:F"

Important: Replace id_ed25519 with your actual key filename if different (e.g., id_rsa, id_ecdsa).

Step 4: Verify the Fix

Check that permissions are now correct:

icacls .\id_ed25519
# You should see output similar to:
#  .\id_ed25519 DESKTOP\YourUsername:(F)

The (F) means Full control, and only your username should be listed.

Step 5: Add Your Key to SSH Agent

Now you can successfully add your key:

ssh-add .\id_ed25519

You should see: Identity added: .\id_ed25519

What These Commands Actually Do

Let’s demystify what just happened:

icacls .\id_ed25519 /inheritance:r

• Translation: “Stop inheriting permissions from the parent folder”
• This removes all the inherited access rules that gave too many people access to your key

icacls .\id_ed25519 /grant:r "%username%:F"

• Translation: “Give only me full control, and remove everyone else”
• %username% = your Windows username (automatically filled in)
• F = Full control (read, write, delete, change permissions)
• The :r means “replace existing permissions” (not just add to them)

You’ve essentially told Windows: “This file is mine and mine alone.”

Never Deal With This Again

Here’s the reality: every time you generate a new SSH key, you’ll need to fix its permissions. Let’s automate it.

Create a PowerShell Function (Recommended)

Add this to your PowerShell profile so it’s always available:

function Fix-SSHPermissions {
    param([string]$KeyPath = "~/.ssh/id_ed25519")
Write-Host "Fixing permissions for $KeyPath..." -ForegroundColor Yellow
    icacls $KeyPath /inheritance:r
    icacls $KeyPath /grant:r "$env:USERNAME`:F"
    Write-Host "✓ Permissions fixed!" -ForegroundColor Green
    Write-Host "You can now run: ssh-add $KeyPath" -ForegroundColor Cyan
}

How to add it to your profile:

1. Open your PowerShell profile:

notepad $PROFILE

2. If you get “file doesn’t exist,” create it first:

New-Item -Path $PROFILE -Type File -Force
notepad $PROFILE

3. Paste the function, save, and reload:

. $PROFILE

Now use it like this:

# Default key
Fix-SSHPermissions
# Specific key
Fix-SSHPermissions -KeyPath ~/.ssh/id_rsa
# Then add to agent
ssh-add ~/.ssh/id_ed25519

Future you will thank present you for setting this up.

The GUI Way (If You Prefer Clicking)

Not a command-line person? You can fix this through File Explorer:

1. Navigate to C:\Users\YourName\.ssh in File Explorer
2. Right-click id_ed25519 → Properties → Security tab → Advanced
3. Click “Disable inheritance” → “Remove all inherited permissions”
4. Click “Add” → “Select a principal” → type your username → “Check Names” → OK
5. Check “Full control” → OK
6. Remove any other users/groups in the list
7. Apply → OK

The PowerShell way is faster once you get used to it. But this works too.

⚠️“It’s Still Not Working” — Troubleshooting

Problem: “Access Denied”

Solution: You need to run PowerShell as Administrator.

• Press Win + X
• Choose “Terminal (Admin)” or “PowerShell (Admin)”
• Click “Yes” when Windows asks for permission

Problem: “Could not open a connection to your authentication agent”

Solution: The ssh-agent service isn’t running. Start it:

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent

Problem: I have multiple keys and this is tedious

Solution: Fix them all at once:

cd ~/.ssh
Get-ChildItem -Filter "id_*" -Exclude "*.pub" | ForEach-Object {
    icacls $_.Name /inheritance:r
    icacls $_.Name /grant:r "$env:USERNAME`:F"
    Write-Host "Fixed: $($_.Name)" -ForegroundColor Green
}

This finds all private keys (files starting with id_ that aren’t .pub files) and fixes their permissions automatically.

Problem: Error still appears after running the fix

1. Verify only your username shows up:

icacls .\id_ed25519

You should see: .\id_ed25519 YourUsername:(F) and nothing else

2. Close and reopen PowerShell/Terminal

3. If all else fails, regenerate your SSH key and apply permissions immediately:

ssh-keygen -t ed25519 -C "[email protected]"
   icacls ~/.ssh/id_ed25519 /inheritance:r
   icacls ~/.ssh/id_ed25519 /grant:r "%username%:F"

Why Windows Does This (And Why It Matters)

Here’s the technical bit, explained simply:

Unix systems (Linux/macOS): Use simple permission bits

• Owner can read/write
• Group can read
• Others have no access

It’s straightforward. A file either has 600 permissions (owner only) or it doesn’t.

Windows: Uses Access Control Lists (ACLs)

• Multiple users can have different levels of access
• Permissions can be inherited from parent folders
• Much more granular, but also more complex

When you create a file in Windows, it inherits permissions from the .ssh folder, which might include access for system accounts, administrators group, or other users. SSH sees this and says “nope, too risky.”

The important part: SSH enforces the same security standard regardless of your OS. Your private key should only be readable by you. Period. This error is SSH doing its job.

Quick Reference Card

Bookmark this section for future reference:

Fix single key:

cd ~/.ssh
icacls .\id_ed25519 /inheritance:r
icacls .\id_ed25519 /grant:r "%username%:F"
ssh-add .\id_ed25519

Fix all keys at once:

cd ~/.ssh
Get-ChildItem -Filter "id_*" -Exclude "*.pub" | ForEach-Object {
    icacls $_.Name /inheritance:r
    icacls $_.Name /grant:r "$env:USERNAME`:F"
}

Verify permissions:

icacls .\id_ed25519
# Should show only: YourUsername:(F)

Start ssh-agent if needed:

Start-Service ssh-agent

Wrapping Up

The “permissions are too open” error is annoying, but it exists for a good reason. Your SSH keys are credentials. Protecting them properly is non-negotiable.

Now you know:

• ✓ How to fix it in 30 seconds
• ✓ Why it happens in the first place
• ✓ How to automate it so you never worry again
• ✓ How to troubleshoot when things go wrong

The next time you generate an SSH key, you’ll fix the permissions without thinking twice.

One More Thing

If you found this helpful, consider:

• Sharing it with a teammate who’s fighting with SSH keys
• Bookmarking it for future reference
• Dropping a comment about what other Windows dev issues frustrate you

Happy Learning!!