Why my SSH key‑based login keeps timing out after a system reboot – and how to fix it with ssh‑config and ssh‑agent -

When you power on a server and hit ssh user@host, the connection dies in a few seconds even though the key works on a fresh machine. The usual suspect is the SSH agent – it’s either not running or not forwarding the key after a reboot. The fix is straightforward: make the agent start automatically, add your key once, and let ssh_config do the rest.

1. Verify the agent is running

ssh-add -l

If you get The agent has no identities, the agent isn’t started or $SSH_AUTH_SOCK isn’t set. On most modern distros the agent is started by the display manager or a systemd‑user unit. Check it with:

systemctl --user status ssh-agent.service

If the unit is inactive, just enable it:

systemctl --user enable --now ssh-agent.service

For headless servers, add a small snippet to your shell’s init file (~/.bash_profile, ~/.profile, etc.):

# Start ssh-agent if not already running
if ! pgrep -u "$USER" ssh-agent > /dev/null; then
    eval "$(ssh-agent -s)"
fi

2. Add your key once

ssh-add ~/.ssh/id_ed25519

If you keep a passphrase, you can let the agent cache it for a while:

ssh-add -t 3600 ~/.ssh/id_ed25519   # 1 hour

Or use keychain for a nicer wrapper if you’re on a multi‑user system.

3. Configure SSH to use the agent automatically

Create or edit ~/.ssh/config:

Host *
    ForwardAgent no
    AddKeysToAgent yes
    UseKeychain yes   # macOS only, ignore on Linux
    IdentityFile ~/.ssh/id_ed25519

AddKeysToAgent yes tells the client to add the key to the agent if it isn’t there yet, so you never need to run ssh-add again after a reboot.

4. Persist the agent across reboots

systemd‑user units keep the agent alive as long as the user session is active. On a console‑only server, a drop‑in keeps the socket alive across reboots:

mkdir -p ~/.config/systemd/user/ssh-agent.service.d
cat > ~/.config/systemd/user/ssh-agent.service.d/override.conf <<EOF
[Service]
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a %t/ssh-agent.socket
EOF
systemctl --user daemon-reload
systemctl --user enable --now ssh-agent.service

Now ssh will automatically pick up the socket and you’re good to go.

5. Troubleshooting quick‑fire

Symptom	What to check	Quick fix
`ssh: connect to host … port 22: Connection timed out`	Network or firewall	Verify `sshd` is listening (`sshd -T
`ssh: Could not resolve hostname …`	DNS	Check `/etc/hosts` or your DNS server.
`ssh: key not found`	Agent not loaded	Run `ssh-add` or ensure the agent starts in your session.
`ssh: Authentication failed`	Wrong key	Make sure the public key is in `~/.ssh/authorized_keys` on the server.

6. Security note

Agents are handy, but any process that can read $SSH_AUTH_SOCK can ask for your key. Keep the socket permissions tight (chmod 700 ~/.ssh/agent.sock) and the agent’s lifetime short (ssh-agent -t 3600). If you’re in a high‑security environment, a hardware token like a YubiKey that never exposes the private key to the host is the safer bet.