Adding a private key to ssh-agent lets the SSH client reuse that identity for later connections without asking for the key's passphrase every time. This is useful for repeated terminal logins, Git over SSH, and other workflows that need the same key more than once in a session.
The ssh-agent process keeps decrypted private keys in memory and exposes a Unix-domain socket through SSH_AUTH_SOCK. The ssh-add command talks to that socket to load or list identities, and current OpenSSH clients automatically query the agent during publickey authentication instead of reopening the private key file for each connection.
Many desktop login sessions already start an agent, while fresh server shells, tmux sessions, or privileged shells may not inherit one. The private key should already exist and remain readable only by its owner, and leaving loaded identities in a long-lived session or forwarding the agent to untrusted hosts increases the impact of local compromise.
Steps to add an SSH key to ssh-agent:
- Open a terminal in the local account that owns the private key.
Run the remaining steps in the same shell session so any new agent environment variables stay available to later commands.
- Check whether the current shell can already reach an authentication agent.
$ ssh-add -l Could not open a connection to your authentication agent.
If the output is The agent has no identities., an existing ssh-agent is already reachable but still empty. If one or more fingerprints appear instead, the current shell is already attached to a running agent with loaded identities.
- Start a new ssh-agent for the current shell if no agent connection is available.
$ eval "$(ssh-agent -s)" Agent pid 365
The eval "$(ssh-agent -s)" command exports SSH_AUTH_SOCK and SSH_AGENT_PID in the current shell so later ssh and ssh-add commands can find the agent socket.
- Add the private key that should be kept in the agent.
$ ssh-add ~/.ssh/id_ed25519 Enter passphrase for /home/user/.ssh/id_ed25519: Identity added: /home/user/.ssh/id_ed25519 (user@example.com)
Replace ~/.ssh/id_ed25519 with the actual private key path when the key uses another name or location. Running ssh-add with no path loads the standard default identity names from ~/.ssh, but using the explicit file is clearer when more than one key exists.
If the private key file is readable by other users, ssh-add ignores it until the permissions are tightened, typically to mode 600 on the file and 700 on ~/.ssh.
Related: How to generate SSH key pairs
- List the fingerprints currently stored in the agent to confirm that the expected identity was loaded.
$ ssh-add -l 256 SHA256:Je7yKmO9x7CnA8hNp6fVUiNzlSRJQw5oSllGSn/qEtg user@example.com (ED25519)
The fingerprint output confirms that the current shell can reach the agent and that the expected key is loaded. If the output is The agent has no identities., the shell can still reach the agent but no private keys are currently stored.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
