How to fix Saving key failed: /home/user/.ssh/id_rsa in SSH

The most common cause is the missing .ssh directory. Create it manually with proper permissions:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Breaking 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 ssh

You should see output like: drwx------ ... .ssh

Ensure the .ssh directory is owned by your user, not root or another user:

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

Or explicitly:

chown -R yourusername:yourusername ~/.ssh

Verify ownership:

ls -la ~/ | grep ssh

The output should show your username in both the owner and group columns:

drwx------ 2 yourusername yourusername 4096 Jan 15 10:30 .ssh

If 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 ~/.ssh

Verify 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-write

If 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.pub

Verify the files exist with correct permissions:

ls -la ~/.ssh/id_ed25519*

You should see:

-rw------- ... id_ed25519
-rw-r--r-- ... id_ed25519.pub

If 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 ssh

If 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).