This error appears when running ssh-add -l and indicates that no SSH keys are loaded in the SSH agent. You need to either generate new SSH keys or add existing keys to the agent using ssh-add.
The "agent has no identities" message indicates that your SSH authentication agent is running but has no SSH keys loaded into it. The SSH agent is a background program that holds your private keys in memory and handles authentication requests from SSH clients like Git. When you run `ssh-add -l` to list loaded keys and see "The agent has no identities," it means: 1. The SSH agent is running (otherwise you'd see "Could not open a connection to your authentication agent") 2. No private keys have been added to the agent yet 3. Any SSH authentication attempts will fail because there are no keys to present to remote servers This is normal behavior after a system restart or new terminal session, as the SSH agent doesn't automatically load keys from disk. Keys must be explicitly added using `ssh-add` each time the agent starts, unless you configure automatic loading.
First, confirm the SSH agent is actually running:
# Check if agent is running
echo $SSH_AUTH_SOCK
# Should output something like: /tmp/ssh-XXXXXX/agent.XXXXXIf the variable is empty or you get "Could not open a connection to your authentication agent," start the agent:
# Start the SSH agent and set environment variables
eval "$(ssh-agent -s)"
# Expected output:
# Agent pid 12345After starting the agent, verify it's running:
ssh-add -l
# Should now show "The agent has no identities" (not a connection error)Look for existing SSH key files in the default location:
# List SSH directory contents
ls -la ~/.ssh/
# Look for key pairs like:
# id_ed25519 / id_ed25519.pub (Ed25519 - recommended)
# id_rsa / id_rsa.pub (RSA - older but common)
# id_ecdsa / id_ecdsa.pub (ECDSA)If you see key files, proceed to add them to the agent (next step).
If no keys exist or the .ssh directory doesn't exist, you need to generate new keys:
# Generate a new Ed25519 key (recommended)
ssh-keygen -t ed25519 -C "[email protected]"
# Or RSA for older systems
ssh-keygen -t rsa -b 4096 -C "[email protected]"Accept the default file location and optionally set a passphrase.
Add your private key to the running SSH agent:
# Add the default Ed25519 key
ssh-add ~/.ssh/id_ed25519
# Or RSA key
ssh-add ~/.ssh/id_rsa
# Or add all default keys at once
ssh-addIf your key has a passphrase, you'll be prompted to enter it.
Verify the key is now loaded:
ssh-add -l
# Should now show something like:
# 256 SHA256:xxxxx [email protected] (ED25519)For keys in non-standard locations:
# Specify the full path
ssh-add /path/to/your/custom_keyStarting with macOS 10.12.2 (Sierra), Apple no longer automatically loads SSH keys into the agent. Configure automatic loading:
# Add key to macOS Keychain
ssh-add --apple-use-keychain ~/.ssh/id_ed25519
# Or the older flag (still works)
ssh-add -K ~/.ssh/id_ed25519Create or edit ~/.ssh/config to persist settings:
# Create the config file if it doesn't exist
touch ~/.ssh/config
chmod 600 ~/.ssh/configAdd these lines to ~/.ssh/config:
Host *
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/id_ed25519This ensures:
- Keys are automatically added to the agent when first used
- Passphrases are stored in macOS Keychain
- The specified key file is used by default
Add SSH agent initialization to your shell profile so keys persist across terminal sessions:
For Bash (~/.bashrc or ~/.bash_profile):
# Start SSH agent if not running
if [ -z "$SSH_AUTH_SOCK" ]; then
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519 2>/dev/null
fiFor Zsh (~/.zshrc), add ssh-agent plugin:
# In ~/.zshrc, add ssh-agent to plugins
plugins=(git ssh-agent)
# Optionally specify identities
zstyle :omz:plugins:ssh-agent identities id_ed25519Then reload your shell:
# Reload shell configuration
exec "$SHELL"
# Or source the config file
source ~/.zshrc # or ~/.bashrcFor systemd-based Linux (persistent agent):
# Enable SSH agent socket (runs automatically)
systemctl --user enable ssh-agent
systemctl --user start ssh-agent
# Add to your shell profile
export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket"SSH requires strict permissions on key files. If permissions are wrong, the agent may refuse to add keys:
# Set correct permissions
chmod 700 ~/.ssh # Directory: owner only
chmod 600 ~/.ssh/id_ed25519 # Private key: owner read/write
chmod 644 ~/.ssh/id_ed25519.pub # Public key: world readable is OK
chmod 600 ~/.ssh/config # Config file: owner only
# Verify permissions
ls -la ~/.ssh/
# Expected output:
# drwx------ .ssh/
# -rw------- id_ed25519
# -rw-r--r-- id_ed25519.pubCommon error if permissions are wrong:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@Important: When using ssh-add, always use the absolute path to the key file:
# Correct - absolute path
ssh-add ~/.ssh/id_ed25519
# May fail - relative path without ~/
ssh-add id_ed25519After adding keys, verify the connection works:
# List loaded identities
ssh-add -l -E sha256
# Test connection to GitHub
ssh -T [email protected]
# Test connection to GitLab
ssh -T [email protected]Expected successful output from GitHub:
Hi username! You've successfully authenticated, but GitHub does not provide shell access.For debugging, use verbose mode:
ssh -vT [email protected]Look for:
- "Offering public key" - agent is presenting keys
- "Server accepts key" - authentication successful
If you still see errors, ensure your public key is added to your GitHub/GitLab account settings.
### Why Keys Don't Persist Across Reboots
The SSH agent is an in-memory process that holds decrypted private keys. When the system shuts down or the agent process terminates, all loaded keys are lost. This is by design - writing decrypted keys to disk would defeat the purpose of having a passphrase.
### SSH Agent Forwarding
When connecting to remote servers, you can forward your local agent to use your keys on the remote machine without copying them:
# Connect with agent forwarding
ssh -A user@remote-server
# On the remote server, your local keys are available
ssh-add -l # Should show your local keysSecurity warning: Only use agent forwarding with servers you fully trust, as a compromised server could potentially use your forwarded keys.
### Using ssh-agent with Keychain on Linux
The keychain utility (from funtoo) can manage ssh-agent across sessions:
# Install keychain
sudo apt install keychain # Debian/Ubuntu
sudo yum install keychain # CentOS/RHEL
# Add to ~/.bashrc
eval "$(keychain --eval --quiet id_ed25519)"### Multiple SSH Keys for Different Services
If you have separate keys for different services:
# ~/.ssh/config
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/github_key
AddKeysToAgent yes
Host gitlab.com
HostName gitlab.com
User git
IdentityFile ~/.ssh/gitlab_key
AddKeysToAgent yes
Host bitbucket.org
HostName bitbucket.org
User git
IdentityFile ~/.ssh/bitbucket_key
AddKeysToAgent yesWith AddKeysToAgent yes, each key is automatically added when first used.
### Troubleshooting Agent Connection Issues
If you see "Could not open a connection to your authentication agent":
# Check if agent is running
ps aux | grep ssh-agent
# If running but connection fails, the socket may be wrong
# Find the correct socket
find /tmp -name "agent.*" -user $USER 2>/dev/null
# Set the socket manually
export SSH_AUTH_SOCK=/tmp/ssh-xxx/agent.xxx### WSL (Windows Subsystem for Linux) Considerations
On WSL, the SSH agent may need special handling:
# Add to ~/.bashrc for WSL
if [ -z "$SSH_AUTH_SOCK" ]; then
export SSH_AUTH_SOCK="$HOME/.ssh/agent.sock"
if ! pgrep -u "$USER" ssh-agent > /dev/null; then
rm -f "$SSH_AUTH_SOCK"
ssh-agent -a "$SSH_AUTH_SOCK" > /dev/null
fi
fiThis creates a persistent socket file that survives WSL restarts.
### Ed25519 vs RSA Keys
For new key generation, Ed25519 is recommended:
| Aspect | Ed25519 | RSA 4096 |
|--------|---------|----------|
| Security | Excellent | Good |
| Key size | 256 bits | 4096 bits |
| Signature speed | Faster | Slower |
| Compatibility | Modern systems | Universal |
Ed25519 keys are smaller and faster while providing equivalent security to RSA 4096.
warning: BOM detected in file, this may cause issues
UTF-8 Byte Order Mark (BOM) detected in file
fatal: Server does not support --shallow-exclude
Server does not support --shallow-exclude
warning: filtering out blobs larger than limit
Git partial clone filtering large blobs warning
fatal: Server does not support --shallow-since
Server does not support --shallow-since in Git
kex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server