SSH-Agent Dilemma/Question(s)

When I follow the github instructions to initially set up my ssh key, authentication works as expected. But, if my workstation goes to sleep, or if it is rebooted, subsequent authentication attempts will fail. After manually running the ssh-agent, authentication attempts will continue to fail. Instead, I find that I must continue to call ssh-agent with the eval command: $ eval $(ssh-agent) even though the Archwiki (and other documentation) seemingly suggests that eval should no longer be necessary.

By the way, the double quotes do not seem to be necessary in this context, as opposed to when the ssh key is initially added to the ssh-agent.

As this is my first encounter with eval, I confess that I’m not confident that I understand everything that I know about it. So, is it normal to continue to require eval, or does this suggest that there is a flaw with the configuration of my host(s)?

The reason I ask is that if my PC goes to sleep, I find that I must manually kill the running ssh-agent process and then once again run $ eval $(ssh-agent), even though ssh-agent is still running (but is not responsive). One of the suggestions of the Archwiki is to have bash run a script that automatically launches ssh-agent at boot, but due to the sleep issue, I think that it makes sense for me to have a bash script that I can run as needed, since I can never seem to remember which punctuation is needed: i.e. the $, brackets and double quotes and of course killing the already running process is a bit tedious.

Here’s the problem, the bash script does, indeed, run ssh-agent at boot as expected, but since I require eval to call it, my authentication attempts fail. If I edit the script and prepend ssh-agent with eval, the script breaks, because of my sub-par scripting abilities.

Here is the aforementioned script and the accompanying notes from the Archwiki - obviously, if I wanted to run this script in the terminal, the file would need to start with #!/bin/bash and have the appropriate permissions:

In order to start the agent automatically and make sure that only one ssh-agent process runs at a time, add the following to your ~/.bashrc :

if [ $(pgrep -u $USER ssh-agent | wc -l) -eq 0 ]; 
    then ssh-agent -t 1h > "$XDG_RUNTIME_DIR/ssh-agent.env"
fi
if [[ ! $SSH_AUTH_SOCK ]]; then
    source "$XDG_RUNTIME_DIR/ssh-agent.env" >/dev/null
fi

This will run a ssh-agent process if there is not one already, and save the output thereof. If there is one running already, we retrieve the cached ssh-agent output and evaluate it which will set the necessary environment variables. The lifetime of the unlocked keys is set to 1 hour.

So, can anyone with better scripting skills than I, help me to understand how to either address the eval issue, mod this script, or perhaps someone has an even more elegant solution to run the ssh-agent? Either way, thanks in advance for your assistance.

BTW: If it matters, you’ve no doubt already determined that I run various flavors of Linux on my workstations, but I am experiencing the same issue with eval in both Manjaro and Solus.

Cheers!

Fundamentally, you don’t need to use eval. That’s mostly a convenience feature for when you start the SSH-Agent manually. What you need are two things:

  • A running SSH-Agent process. It creates a socket in the filesystems that clients can connect to when they want to use the agent (e.g. when Git calls SSH to connect to GitHub).
  • The path to that socket must be set in the SSH_AUTH_SOCK environment variable. That’s how clients find the agent.

I’ve never seen SSH-Agent break during suspend, so I’m pretty sure whatever happens isn’t that. Could be that something stops the agent or clears its keys (e.g. as a security measure to make sure keys aren’t in RAM if your laptop gets stolen while suspended). Or something messes with the environment variables on suspend/resume (though that’d be pretty unusual).

Another thing to consider: With most desktop environments you shouldn’t need to run SSH-Agent manually. It should be started when your user session is started, or at least there should be an option to enable that.

I can’t say what exactly may be going wrong without a lot more details on your setup.