The "Saving key failed" error occurs when ssh-keygen cannot write the generated SSH key files to the specified directory. This is typically caused by missing .ssh directory, incorrect file permissions, or insufficient disk space. Fix it by ensuring the directory exists with proper permissions and disk space is available.
The "Saving key failed" error means ssh-keygen has generated your SSH key pair successfully but cannot write the private key file to the filesystem. This is a file I/O issue, not a key generation problem. The error indicates one of these scenarios: 1. **Missing .ssh directory**: The default `~/.ssh` directory doesn't exist. SSH is strict about directory structure and won't auto-create it. 2. **Incorrect directory permissions**: The `~/.ssh` directory or its parent directory has permissions that prevent write access. 3. **Disk full or read-only filesystem**: The filesystem is out of space or mounted as read-only. 4. **Inaccessible path**: You're trying to save to a location your user doesn't have permission to write to (e.g., system directories without sudo). 5. **File already exists with wrong permissions**: A key file already exists but is owned by a different user or has restrictive permissions.
The most common cause is the missing .ssh directory. Create it manually with proper permissions:
mkdir -p ~/.ssh
chmod 700 ~/.sshBreaking this down:
- mkdir -p ~/.ssh creates the directory (and parent directories if needed)
- chmod 700 ~/.ssh sets permissions to drwx------ (read, write, execute for owner only)
Verify the directory was created correctly:
ls -la ~/ | grep sshYou should see output like: drwx------ ... .ssh
Ensure the .ssh directory is owned by your user, not root or another user:
chown -R $(whoami):$(whoami) ~/.sshOr explicitly:
chown -R yourusername:yourusername ~/.sshVerify ownership:
ls -la ~/ | grep sshThe output should show your username in both the owner and group columns:
drwx------ 2 yourusername yourusername 4096 Jan 15 10:30 .sshIf ssh-keygen was run with sudo, the directory may be owned by root. Fix it by running chown as root:
sudo chown -R $USER:$USER ~/.sshVerify there's sufficient disk space available:
df -h ~/Look for your home partition in the output. If you see 100% in the "Use%" column, your disk is full. Free up space by:
- Removing large files or temporary directories
- Clearing package manager caches (if applicable)
- Moving files to external storage
Also check if the filesystem is read-only:
touch ~/.ssh/test-write && rm ~/.ssh/test-writeIf this fails with "Read-only file system", remount the filesystem with write permissions (you may need sudo):
mount | grep "on /home"The home directory parent also affects access. Check home directory permissions:
ls -ld ~/You should see something like: drwxr-xr-x ... yourusername yourusername ...
The home directory should be at least 755 (drwxr-xr-x). If it's more restrictive (e.g., 700), this could prevent .ssh access. However, most home directories are 755 by default.
If the home directory is owned by root or another user, this is a serious permission issue. Contact your system administrator if you cannot modify it.
Once the .ssh directory is properly set up, run ssh-keygen again:
ssh-keygen -t ed25519 -C "[email protected]"When prompted for the file location, press Enter to accept the default /home/yourusername/.ssh/id_ed25519:
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/yourusername/.ssh/id_ed25519): [Press Enter]
Enter passphrase (empty for no passphrase): [Enter your passphrase or leave blank]
Enter same passphrase again: [Repeat passphrase]The keys should be created successfully:
Your identification has been saved in /home/yourusername/.ssh/id_ed25519
Your public key has been saved in /home/yourusername/.ssh/id_ed25519.pubVerify the files exist with correct permissions:
ls -la ~/.ssh/id_ed25519*You should see:
-rw------- ... id_ed25519
-rw-r--r-- ... id_ed25519.pubIf you're on WSL, a NFS-mounted home, or a system with strict security policies, use verbose mode to diagnose the issue:
ssh-keygen -v -t ed25519 -C "[email protected]"The -v flag shows detailed output about where it's trying to save the file.
WSL (Windows Subsystem for Linux): Windows directories mounted in WSL have permission quirks. Store your keys in the native WSL filesystem (/home/yourusername) rather than in /mnt/c/ (Windows directory).
NFS mounts: If your home is on an NFS mount with nowrite or similar options, ask your system administrator to adjust the mount options.
SELinux/AppArmor: Check security module logs:
# For SELinux systems
sudo ausearch -m avc | grep ssh
# For AppArmor systems
sudo dmesg | grep apparmor | grep sshIf you see denial logs, your security policy is blocking ssh-keygen. You may need to adjust the policy or run ssh-keygen with elevated privileges (though this is not recommended).
Key Type Selection: While ed25519 is recommended for new keys (smaller, faster, more secure), you can also use RSA with -t rsa -b 4096 for compatibility with older systems. The error "Saving key failed" occurs regardless of key type.
Passphrase Security: Always use a strong passphrase when prompted during key generation (unless you need a passwordless key for automation). This protects your private key if it's ever accessed by unauthorized users.
Multiple Keys: You can generate multiple keys for different purposes (e.g., one for GitHub, one for work servers). Use the -f flag to specify different filenames:
ssh-keygen -t ed25519 -f ~/.ssh/github_key -C "[email protected]"
ssh-keygen -t ed25519 -f ~/.ssh/work_key -C "[email protected]"Then configure ~/.ssh/config to use the appropriate key for different hosts.
Private Key Permissions: SSH strictly enforces private key permissions and will refuse to use keys with permissions other than 600 (-rw-------). If you manually copy a key, always set permissions:
chmod 600 ~/.ssh/id_rsaDebugging Write Failures: If you continue to have write failures, strace can help identify the exact system call that fails:
strace -e openat,mkdir ssh-keygen -t ed25519This shows each file operation and whether it succeeds or fails, helping identify permission or filesystem issues.
Migrating from RSA: If you have old RSA keys, you can regenerate them as ED25519, which is now the default on modern systems. The tradeoff is that very old systems may not support ED25519.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH