Git SSH: Passphrase Prompted Even After Caching Credentials

Understanding the SSH Agent Mechanism

The ssh-agent is a background process designed to hold private keys used for public key authentication in one place. When you start this agent, it creates a socket file that allows client applications, such as git, to communicate with it securely. If the agent is not running, or if your terminal session does not know where to find it, every SSH command will trigger a fresh prompt for your passphrase.

In Windows environments using Git Bash, this issue is particularly common because the shell initialization scripts may not automatically launch the agent or export the necessary connection details. Without these exports, Git falls back to standard interactive authentication, ignoring any previous caching attempts. Proper configuration ensures that once you enter your passphrase, subsequent operations within the same session bypass the prompt entirely.

Verifying Agent Status

Before attempting complex fixes, verify whether an agent is currently active. Run the following command in your Git Bash terminal:

echo $SSH_AUTH_SOCK

If this command returns an empty line, no agent is connected. If it returns a path like /tmp/ssh-XXXXXX/agent.XX, an agent is running but may not have your key loaded. Check loaded keys with:

ssh-add -l

An empty output here confirms that while an agent might exist, it holds no keys, forcing Git to ask for credentials repeatedly.

Configuring Git Bash on Windows

To resolve persistent prompts, you must ensure the SSH agent starts correctly and persists across sessions. The most reliable method involves modifying your .bashrc or .profile file located in your home directory (%USERPROFILE%).

1. Open your .bashrc file in a text editor.
2. Add the following snippet to initialize the agent only if it is not already running:

if [ -z "$SSH_AUTH_SOCK" ]; then
    eval $(ssh-agent -s)
    echo "SSH Agent started."
fi

This code checks if the environment variable SSH_AUTH_SOCK is set. If it is missing, it launches a new agent instance and evaluates its output to set the required variables for the current shell. This ensures that every new Git Bash window has access to the agent immediately upon opening.

Loading Your Key Automatically

Starting the agent is insufficient; you must also load your specific private key into it. Add the following line to your .bashrc below the agent initialization block:

ssh-add ~/.ssh/id_rsa

Replace id_rsa with the filename of your actual private key if it differs. This command triggers the passphrase prompt only once per session. Subsequent Git commands will use the cached key from the agent, eliminating repetitive requests. Note that you must enter your passphrase every time you restart your computer or log out, as the agent’s memory is volatile.

Alternative: Using OpenSSH Configuration

If you prefer not to modify shell scripts, you can configure the SSH client to handle agents differently via the ~/.ssh/config file. This method is often cleaner for managing multiple keys.

• Create or edit ~/.ssh/config.
• Add the following global settings:

Host *
    AddKeysToAgent yes

The AddKeysToAgent yes directive tells the SSH client to automatically add any unlocked keys to the running agent. This removes the need for manual ssh-add commands in your startup scripts. However, this feature requires OpenSSH version 7.2 or later, which is standard in modern Git for Windows distributions.

Troubleshooting Common Errors

Even with correct configuration, issues may persist due to permission errors or conflicting processes.

Permission Denied Issues

Ensure your private key file has restricted permissions. On Windows, this is less critical than on Linux, but Git Bash may still enforce strict checks. Verify permissions using:

ls -la ~/.ssh/id_rsa

The file should typically be readable and writable by the owner only. If permissions are too open, SSH may refuse to use the key silently or prompt unexpectedly.

Conflicting Agents

Sometimes, other applications like GitHub Desktop or Visual Studio Code may spawn their own SSH agents, causing conflicts. Ensure you are using the agent launched by your Git Bash profile, not a background service from another IDE. You can kill all existing agents with ssh-agent -k before restarting your terminal to clear the state.

Frequently Asked Questions

Why does Git still ask for a passphrase after I added the key?

This usually happens because the key was added to a different agent instance than the one Git is communicating with. Ensure you are using the same terminal session where you ran ssh-add, or verify that $SSH_AUTH_SOCK points to the correct socket.

How do I remove a passphrase from my SSH key permanently?

You can generate a new key without a passphrase using ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -N "". Be aware that storing keys without passphrases reduces security, as anyone gaining access to your machine can use the key. For more on securing your setup, see Verifying Passphrase Security for a Newly Generated SSH Key Locally.

Can I cache the passphrase for the entire day instead of just the session?

Standard OpenSSH agents clear their memory when the process terminates. To persist longer, you can configure the agent to remember keys for a specific duration using ssh-add -t 8h, which caches the key for eight hours. This balances convenience with periodic re-authentication requirements.

What if I am using PuTTY instead of Git Bash?

PuTTY uses pageant as its SSH agent. You must load your .ppk key into Pageant manually or via startup shortcuts. Git Bash does not interact with Pageant unless specifically configured, so switching clients requires separate agent management steps.

Is it safe to leave the SSH agent running indefinitely?

While convenient, leaving the agent running exposes your decrypted key to any process that can connect to the agent socket. It is recommended to stop the agent when not working, especially on shared computers. You can automate stopping it by adding ssh-agent -k to your logout scripts.