SSH authentication fails when the SSH agent cannot sign your key. This typically occurs when your SSH key isn't loaded in the agent or the agent has configuration issues, preventing authentication to GitHub or other SSH servers.
This error means your SSH agent was unable to use your private key to authenticate your identity. When you attempt an SSH connection, the server asks your client to prove it owns a specific key. The SSH agent is responsible for this signing process, but something is preventing it from working—either the key isn't loaded, the agent is misconfigured, or there's a compatibility issue with your key type or agent implementation.
First, verify your SSH agent is running and load your key:
eval "$(ssh-agent -s)"
ssh-addThis starts the SSH agent in the background and adds your default SSH key (~/.ssh/id_rsa). Test your connection:
ssh -vT [email protected]If you see "Hi username! You've successfully authenticated," the issue is resolved.
If your key isn't in the default location, explicitly add it:
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/my_custom_keyReplace my_custom_key with your actual key filename. You can add multiple keys:
ssh-add ~/.ssh/id_rsa
ssh-add ~/.ssh/id_ed25519
ssh-add ~/.ssh/github_personal_keyVerify all loaded keys with:
ssh-add -lOn Ubuntu, GNOME Keyring sometimes intercepts SSH requests but fails to handle certain key formats. Test if it's the problem:
SSH_AUTH_SOCK=0 ssh -vT [email protected]If this works, GNOME Keyring is likely the culprit. To permanently fix this on Ubuntu:
1. Reboot your system
2. Open Unity's Dash (or Activities menu)
3. Search for and open "Startup Applications"
4. Uncheck "SSH Key Agent"
5. Reboot again
After reboot, run eval "$(ssh-agent -s)" and ssh-add to use the standard SSH agent instead.
To quickly test if the agent is the problem without making changes:
ssh -o IdentityAgent=none -vT [email protected]This bypasses the SSH agent entirely. If this works, the issue is definitely with your agent configuration. You can make this permanent by adding it to ~/.ssh/config:
Host github.com
IdentityAgent noneHowever, this is a workaround—investigate and fix the actual agent issue for better security and flexibility.
To ensure the SSH agent runs every time you open a terminal, add this to your ~/.bashrc or ~/.zshrc:
if [ -z "$SSH_AUTH_SOCK" ]; then
eval "$(ssh-agent -s)"
ssh-add
fiThis checks if an agent is already running before starting a new one, preventing multiple agent processes. Reload your shell:
source ~/.bashrc # or source ~/.zshrcNow your SSH keys will be automatically loaded when you open a new terminal.
On macOS, the ssh-agent is managed by Keychain and typically works correctly. If you see this error on macOS, check if you're using a third-party SSH agent that's incompatible. On Linux, some desktop environments (GNOME, KDE) try to manage SSH keys automatically, but may have bugs or compatibility issues—using the standard SSH agent often resolves problems.
For ed25519 keys, there are rare edge cases where certain SSH agent implementations don't fully support this key type. If ed25519 keys fail but RSA keys work, try using RSA instead or updating your SSH client and agent to the latest versions.
If you're connecting through a firewall, VPN, or bastion host, the problem may not be the agent—test direct SSH connectivity first.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH