Why id_rsa Works Without ssh-add but id_ed25519 Doesn’t

2 min read

Many users notice that id_rsa works without manually adding it to the agent, while id_ed25519 does not. This difference usually comes down to defaults and legacy behavior.

Root Cause

SSH automatically looks for keys with default filenames, and historically id_rsa has been the most common one. On many systems:

  • Desktop environments or keyring services automatically load id_rsa

  • id_rsa may not have a passphrase, allowing SSH to use it directly

  • SSH tries id_rsa first and succeeds before checking other keys

In contrast, id_ed25519 is newer, more secure, and often protected by a passphrase. SSH will not automatically load it unless explicitly configured, so it requires ssh-add or proper agent setup.


Modern best practice is to use id_ed25519 and configure SSH to manage it properly. This gives you stronger cryptography while keeping the convenience of agent-based authentication.

By understanding how SSH agents work and why keys behave differently, you can avoid confusion and set up a more secure and predictable SSH workflow.

How to avoid typing this every time

You have a few good options:

Add this to ~/.bashrc or ~/.zshrc:

if [ -z "$SSH_AUTH_SOCK" ]; then   eval "$(ssh-agent -s)"   ssh-add ~/.ssh/id_ed25519 2>/dev/null 
fi

✅ Option 2: Use a keychain manager

Install keychain:

sudo apt install keychain

Then add to your shell config:

eval "$(keychain --eval --quiet id_ed25519)"

✅ Option 3: Use SSH config

In ~/.ssh/config:

Host github.com   AddKeysToAgent yes   IdentityFile ~/.ssh/id_ed25519

(This still needs an agent running, but helps auto-add.)

Quick check

Run:

ssh-add -l

  • If empty → agent has no keys

  • If listed → you’re good