Why is ssh-agent ignoring the lifetime in .ssh/config?

Question

I can't get ssh-agent to work like I want to. It keeps removing the saved identities on reboot.

I use AddKeysToAgent in my .ssh/config like this:

AddKeysToAgent 30w

That's the top of the file, followed by Host definitions. I also tried it like this

Host *
  AddKeysToAgent 30w

with no success.

My identities are remembered when I ssh to a server as intended. They are remembered when I close the terminal and open it again, but they are lost when I reboot. I can use ssh-add -l to see them or verify there are no identities saved after a reboot.

There is only one ssh-agent running. It is started from .bashrc like this:

if ! pgrep -u "$USER" ssh-agent > /dev/null; then
    ssh-agent > "/home/deck/.ssh-agent.env"
fi
if [ ! -f "$SSH_AUTH_SOCK" ]; then
    source "/home/deck/.ssh-agent.env" >/dev/null
fi

As mentioned, it works. It just ignores the lifetime defined in .ssh/config.

What could be the reason? Are there any max values, defaults, overrides? Is there some master setting that says "on reboot kill all"?

This is on SteamOS, an Arch-derived OS that comes with KDE Plasma.

SSH -V: OpenSSH_9.9p1, OpenSSL 3.4.0 22 Oct 2024

Answer 1

The "vanilla" OpenSSH ssh-agent doesn't even try to persist unlocked identities on disk. Doing that even half-way securely would require using a TPM or similar security hardware, and interfacing with that requires a lot of OS-specific code the Portable OpenSSH project would not want to maintain.

A SSH agent with an unlocked identity is just as unsafe as a SSH private key with no passphrase: anyone who can access the key file/agent socket will usually be free to perform as many authentication attempts with it as they can.

So, the maximum lifetime of an unlocked SSH identity is either the AddKeysToAgent time value, or the lifetime of the ssh-agent process, whichever is less.

There are alternative SSH agent implementations with somewhat different behavior: e.g. the optional SSH agent functionality of a GPG agent, for example.

---

If you need SSH identities available without authentication for e.g. automation purposes, a more secure way might be to use passphraseless SSH keys, but to specify a fixed command/action for such keys at the remote ~/.ssh/authorized_keys file (or equivalent). That way, even if an attacker gets an unprotected private key, the only thing they will be able to do with it is to trigger that one specific pre-determined action that key is tied to.

The flipside is, you will need to create a separate SSH key for each action you wish to trigger remotely in a non-interactive way.

Answer 2

Obviously if ssh-agent keeps your key un-encrypted in memory, how should that survive a reboot or restart of the process? Apart form that the ID of the agent will also change on restart or reboot.

For example after running eval $(ssh-agent) the output says "Agent pid 15448", and in the environment I see:

SSH_AUTH_SOCK=/tmp/ssh-XXXXXXGT3AIL/agent.15447
SSH_AGENT_PID=15448

So the agent is using the temporary "unix" socket to listen for requests. Typically that socket also won't survive reboot.