How to fix key_write failed in SSH

SSHINTERMEDIATEMEDIUMUpdated Jan 4, 2026· 186 views

This error occurs when SSH cannot write a key file to disk. Common causes include permission issues on the .ssh directory, insufficient disk space, or a read-only filesystem. The fix depends on identifying whether the problem is permissions, storage, or file system access.

Quick fix

Fixes key_write failed

ls -ld ~/.ssh
  1. Check and fix .ssh directory permissions
  2. Fix .ssh directory ownership
  3. Verify sufficient disk space
  4. Check for immutable flag on existing key
ssh — error
ls -ld ~/.ssh
key_write failed

What this error means

The "key_write failed" error appears when OpenSSH (ssh-keygen, ssh-add, or SSH client) attempts to write or save a key file but fails at the filesystem level. This typically happens during key generation with ssh-keygen or when the SSH client tries to cache a key. Unlike authentication failures, this is a system-level I/O error—SSH has already decided what needs to be written but cannot complete the operation due to permissions, disk space, or filesystem restrictions.

Typical symptoms

  • ssh-keygen command fails while generating a new key pair
  • Error appears when saving generated key: 'key_write failed: Permission denied'
  • SSH connection fails when trying to save host key verification
  • Error occurs even with sudo or elevated privileges
  • Operations work fine in some directories but fail in .ssh
  • Recent disk space warnings or 'No space left on device' messages

Common causes

  1. Incorrect permissions on ~/.ssh directory (should be 700, not 755 or 777)
  2. Incorrect ownership of ~/.ssh directory (should be owned by current user, not root or another user)
  3. Insufficient disk space to write the key file
  4. Filesystem mounted as read-only or with nowrite restrictions
  5. SELinux or AppArmor policy preventing writes to .ssh
  6. Key file already exists with immutable flag set
  7. Corrupted filesystem requiring fsck repair
  8. Home directory on network mount with permission restrictions

How to fix "key_write failed"

1Check and fix .ssh directory permissions

SSH requires the .ssh directory to have restrictive permissions (700). Check current permissions:

bash
ls -ld ~/.ssh

Should show: drwx------ (700)

If permissions are wrong, fix them:

bash
chmod 700 ~/.ssh

If the directory doesn't exist, create it:

bash
mkdir -p ~/.ssh
chmod 700 ~/.ssh
2Fix .ssh directory ownership

The .ssh directory must be owned by the current user, not root or another user. Check ownership:

bash
ls -ld ~/.ssh

Should show: user user (your username for both owner and group)

If ownership is wrong, fix it:

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

Or explicitly:

bash
chown -R $(whoami):$(whoami) ~/.ssh

This is especially important if you previously ran ssh commands with sudo.

3Verify sufficient disk space

Check if your filesystem has enough free space:

bash
df -h

Look for the partition containing /home (or ~). If it shows 100% or very close (95%+), you're out of space.

Free up space by:

bash
# Find large files in home directory
du -sh ~/* | sort -h

# Remove unnecessary files
rm -rf ~/Downloads/*  # or other large directories
rm -rf ~/.cache/pip   # Python cache

Then retry the key operation.

4Check for immutable flag on existing key

If a key file already exists, it may have the immutable attribute set. Check:

bash
lsattr ~/.ssh/id_rsa 2>/dev/null || echo "File doesn't exist or no extended attributes"

If you see an 'i' flag (immutable), remove it:

bash
sudo chattr -i ~/.ssh/id_rsa

Then retry the operation.

5Generate key in a writable location first

If your .ssh directory has issues, generate the key elsewhere temporarily and move it:

bash
# Generate in /tmp (always writable)
ssh-keygen -t rsa -b 4096 -f /tmp/id_rsa_temp

# Move to .ssh with correct permissions
mv /tmp/id_rsa_temp ~/.ssh/id_rsa
mv /tmp/id_rsa_temp.pub ~/.ssh/id_rsa.pub
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub

This works around temporary permission issues.

6Check for SELinux or AppArmor restrictions

On systems with SELinux (RHEL/CentOS) or AppArmor (Ubuntu), security policies might block writes. Check if either is active:

bash
# Check SELinux (RHEL/CentOS)
getenforce

# Check AppArmor (Ubuntu)
aa-status 2>/dev/null || echo "AppArmor not installed"

If SELinux shows "Enforcing", check the context:

bash
ls -laZ ~/.ssh

If the context is wrong, fix it:

bash
restorecon -R ~/.ssh

For AppArmor, check the profile:

bash
sudo aa-status | grep -i ssh

If the profile is in Enforce mode and blocking, consider switching to Complain mode temporarily for debugging.

7Check if filesystem is read-only

If the filesystem is mounted read-only, no writes will succeed. Check:

bash
mount | grep "on / "

If you see "ro" (read-only), remount as read-write:

bash
sudo mount -o remount,rw /

Also check the home filesystem:

bash
mount | grep "on /home"

If it's read-only, remount it:

bash
sudo mount -o remount,rw /home
8Regenerate the SSH key

After fixing permissions and disk space, generate a fresh key:

bash
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -N ""

Or for ED25519 (newer, recommended):

bash
ssh-keygen -t ed25519 -f ~/.ssh/id_rsa -N ""

The -N "" skips the passphrase prompt. Verify it created successfully:

bash
ls -la ~/.ssh/id_rsa*

Should show:
- -rw------- (600) id_rsa (private key)
- -rw-r--r-- (644) id_rsa.pub (public key)

Advanced notes

Advanced troubleshooting:

WSL (Windows Subsystem for Linux): WSL filesystems sometimes have permission caching issues. If you've recently changed permissions or ownership, try restarting WSL:

bash
# Exit WSL and run from Windows PowerShell:
wsl --shutdown

# Then re-enter WSL and retry

NFS/Remote Home Directories: If your home directory is on a network mount (NFS, SMB), the mount options might restrict permissions. Check with your system administrator to ensure the mount includes write access.

Docker/Container Environments: Inside containers, if /home is mounted read-only or as a volume without proper permissions, SSH operations will fail. Ensure the volume is mounted with correct permissions:

bash
docker run -it -v /home/user/.ssh:/home/user/.ssh:rw ...

Debugging with strace: For obscure filesystem issues, trace the exact syscall failure:

bash
strace -e openat,write ssh-keygen -t rsa -f ~/.ssh/test_key 2>&1 | tail -20

This shows exactly which syscall is failing and why (EACCES = permission, ENOSPC = no space, EROFS = read-only fs).

Filesystem Corruption: If all else fails and you suspect disk corruption, run a filesystem check:

bash
# For ext4 (requires unmounting)
sudo fsck.ext4 -y /dev/sdaX

# Check without repair first
sudo fsck.ext4 -n /dev/sdaX

Frequently asked questions

What does "key_write failed" mean?
The "key_write failed" error appears when OpenSSH (ssh-keygen, ssh-add, or SSH client) attempts to write or save a key file but fails at the filesystem level. This typically happens during key generation with ssh-keygen or when the SSH client tries to cache a key. Unlike authentication failures, this is a system-level I/O error—SSH has already decided what needs to be written but cannot complete the operation due to permissions, disk space, or filesystem restrictions.
How do I fix "key_write failed"?
This error occurs when SSH cannot write a key file to disk. Common causes include permission issues on the .ssh directory, insufficient disk space, or a read-only filesystem. The fix depends on identifying whether the problem is permissions, storage, or file system access.
What causes "key_write failed"?
Incorrect permissions on ~/.ssh directory (should be 700, not 755 or 777) Incorrect ownership of ~/.ssh directory (should be owned by current user, not root or another user) Insufficient disk space to write the key file
Is the "key_write failed" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading