Introduction

If Git keeps asking for your SSH key passphrase, the most likely reason is simple: your private key is encrypted, but nothing is caching the unlocked key between commands. That is normal security behavior, not a Git bug. The fix is usually to load the key into ssh-agent or your OS keychain so Git can reuse it without prompting every time.

Why the Prompt Keeps Appearing

When Git talks to a remote over SSH, it delegates authentication to your SSH client. If your private key is protected with a passphrase, the SSH client must unlock it before it can authenticate.

Without an agent, this can happen on every git pull, git push, or git fetch.

You can confirm the remote is using SSH with:

git remote -v

If the remote looks like [email protected]:owner/repo.git, Git is using SSH. If it looks like https://..., your problem is different.

Load the Key into ssh-agent

On macOS and Linux, the usual fix is to start ssh-agent and add your key once per login session.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Use your real private key path if it is not id_ed25519.

After adding the key, test SSH authentication directly:

ssh -T [email protected]

If the agent is working, Git operations should stop asking for the passphrase repeatedly during that session.

macOS Keychain Integration

On macOS, you can make this smoother by telling SSH to store the passphrase in the keychain and auto-add the key to the agent.

In ~/.ssh/config:

1Host github.com
2    AddKeysToAgent yes
3    UseKeychain yes
4    IdentityFile ~/.ssh/id_ed25519

Then add the key with keychain support:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

This is usually the most convenient setup for a Mac development machine because the passphrase survives terminal restarts without removing the key’s protection.

Linux and Other Unix-Like Systems

On Linux, desktop environments often start an SSH agent automatically. If not, starting it manually and adding the key is enough for most shell-based workflows.

You can inspect loaded keys with:

ssh-add -l

If that command reports no identities, the agent is running but your key is not loaded yet.

If it says it cannot connect to the authentication agent, the agent environment variables are missing and you need to start or reattach to the agent.

Windows Notes

On Windows, the OpenSSH Authentication Agent service can store the unlocked key for you. After starting the agent, add the key with:

ssh-add $HOME\.ssh\id_ed25519

If you use Git tools that bundle their own SSH client, make sure they are using the same agent and key paths you expect.

Do Not "Fix" It by Removing the Passphrase Unless You Mean To

It is possible to remove the passphrase from a key, but that is a security tradeoff, not a convenience setting. A passphrase protects the key if the private key file is copied or your machine is compromised at rest.

If convenience is the goal, using an agent or keychain is usually the better solution.

Common Pitfalls

One common problem is adding the wrong key. If your Git host is expecting ~/.ssh/id_ed25519_work but you loaded id_rsa, the prompt may continue because SSH is still trying several keys or falling back incorrectly.

Another issue is missing or overly broad SSH config. If the Host entry does not match the actual remote host, options like UseKeychain and IdentityFile may never apply.

Permissions can also matter. Private keys should not be world-readable. If SSH refuses to use the key, fix permissions with something like chmod 600 ~/.ssh/id_ed25519.

Finally, some developers accidentally use HTTPS remotes in one repository and SSH remotes in another, then assume one fix should cover both.

Summary

• Repeated passphrase prompts usually mean your SSH key is encrypted and not cached by an agent.
• Start ssh-agent and add the key with ssh-add.
• On macOS, UseKeychain yes and AddKeysToAgent yes make the workflow smoother.
• Verify that your Git remote is actually using SSH and that the correct key is loaded.
• Prefer using an agent or keychain over removing the passphrase from the private key.