SSH Agent: Use Passphrase-Protected Keys Without Repeated Prompts

A passphrase protects an SSH private key on disk, but entering it for every connection gets old quickly. ssh-agent solves that by keeping a decrypted key in memory and signing authentication requests when SSH tools need it.

That makes it a convenience with a security tradeoff: the key stays protected on disk, but access to the running agent can be used to authenticate as you. Here’s how to load a key, check what’s available, and keep the agent’s boundaries clear.

Load a key into the agent

On macOS or Linux, first check whether an agent is already available:

ssh-add -l

If it lists fingerprints, the current shell can reach an agent and those identities are already loaded. If no agent is available, start one and add your key:

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

You’ll be prompted for the key’s passphrase. Once loaded, the key can be used by ssh, scp, sftp, and Git over SSH without asking for that passphrase again during the agent’s lifetime.

The eval is important: ssh-agent -s prints shell commands that set variables such as SSH_AUTH_SOCK. eval runs those commands in your current shell, so programs launched from it can find the agent. Starting another terminal does not necessarily give that shell access to the same agent environment.

On many Linux desktop environments and on macOS, the login session may already start an agent. Checking with ssh-add -l before running eval "$(ssh-agent -s)" avoids starting a redundant one.

On macOS, you can ask ssh-add to store the passphrase in Keychain:

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

If you want to understand why agent-aware tools depend on SSH_AUTH_SOCK, see this explanation of how SSH finds the agent socket.

Windows uses a service

Windows OpenSSH provides the agent as a background service. From an elevated PowerShell prompt, check its state, configure it to start automatically, and start it:

Get-Service ssh-agent
Set-Service -Name ssh-agent -StartupType Automatic
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

After the service is running, ssh-add can communicate with it without the Unix-like eval step. The commands above enable automatic startup; use an elevated prompt for the service configuration and start commands.

What happens during authentication?

The agent is not a network proxy, and it does not send your private key to the SSH server. Instead, the SSH client asks the agent to sign authentication data using a loaded key. The agent returns the signature, and the server checks it against the corresponding public key.

The SSH key proves your identity during authentication. It does not encrypt the session itself; SSH negotiates separate keys to protect the connection’s traffic.

If you already use a passphrase-protected key for several connections, an agent can save repeated prompts. If your key has no passphrase, or you’re making a one-off connection, you may not need one just for convenience.

See what’s loaded—and limit how long it stays

Use these commands to inspect and manage identities:

ssh-add -l                         # List fingerprints of loaded keys
ssh-add -L                         # Print the loaded public keys
ssh-add -t 3600 ~/.ssh/id_ed25519  # Load a key for one hour
ssh-add -d ~/.ssh/id_ed25519       # Remove one key from the agent
ssh-add -D                         # Remove all keys from the agent

A key added without a timeout remains loaded until you remove it or the agent stops. ssh-add -D clears identities from the agent; it does not delete your key files.

If ssh-add -l says “The agent has no identities,” the agent is reachable but no keys are loaded. If it says “Could not open a connection to your authentication agent,” the current shell cannot reach an agent. On Unix-like systems, check whether SSH_AUTH_SOCK is set in that shell; a working agent in another terminal does not guarantee this one can use it.

Agent forwarding is a separate decision

Using a local agent to connect from your computer is different from forwarding it to a remote server. Forwarding lets the remote machine request signatures through your agent while the connection is active. It does not give that machine the private key file, but someone with sufficient privileges on the remote host may be able to use the forwarded agent to authenticate as you.

Only enable forwarding when you need it, for example with ssh -A. If you’re deciding whether to forward an agent or connect through an intermediate machine another way, review the security tradeoffs of SSH agent forwarding.

The practical rule: load keys only into an agent you trust, use a timeout when it fits your workflow, and don’t forward your agent to a host you don’t trust.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.