1. Overview
ssh-agent is an essential tool for managing SSH (Secure Shell) keys and providing secure access to remote servers without repeatedly entering passphrases. For more context, SSH is a protocol that manages secure remote logins and serves as the base for other network protocols.
Occasionally, there might be a need to restart the ssh-agent daemon due to different reasons:
- change in the SSH keys
- resolving agent-related issues
In this tutorial, we’ll focus on learning how to restart ssh-agent without logging out and logging in. In general, we’ll understand the usage of this agent in Unix-like operating systems like Linux and macOS.
2. Understanding ssh-agent
In general, ssh-agent is a program that runs in the background and holds private keys used for public key authentication.
It caches decrypted private keys and uses them for logins without re-entering the passphrase every time.
Firstly, we can check the status of ssh-agent to know if it’s running in the current shell session:
$ ps aux | grep ssh-agent
kali 1415 0.0 0.0 8612 1400 ? Ss May17 0:00 /usr/bin/ssh-agent x-session-manager
kali 2053793 0.0 0.0 6344 2176 pts/0 S+ 22:51 0:00 grep --color=auto ssh-agent
As shown above, the ps aux command outputs the process status for all processes and provides detailed information about each. Furthermore, the grep command filters by string ssh-agent from the list of processes.
Apart from the command /usr/bin/ssh-agent x-session-manager in the last column (eleven), two columns from the output above are of importance in this case. The second column holds the process IDs, so it tells us that the ssh-agent process ID is 1415. Meanwhile, column eight displays the process status as Ss. To clarify, the Ss status indicates the respective process is sleeping (S) and is a session leader (s).
For comparison, we can obtain the process ID (PID) of the ssh-agent via the pidof command:
$ pidof ssh-agent
1415As shown above, the process ID correlates with the previous output.
3. Restarting ssh-agent
To practically demonstrate restarting the ssh-agent process, we terminate and restart it without logging out. Let’s go through each of these steps consecutively for a successful ssh-agent restart.
3.1. Terminate the Process
The process ID information obtained previously can be used to terminate the ssh-agent process via the kill command:
$ kill 1415The current status of the ssh-agent processes can be checked with the ps aux command output filtered and piped into the grep command that searches for the ssh-agent pattern:
$ ps aux | grep ssh-agent
kali 1415 0.0 0.0 0 0 ? Zs May17 0:01 [ssh-agent] <defunct>
kali 2070416 0.0 0.0 6344 2176 pts/0 S+ 23:25 0:00 grep --color=auto ssh-agent
Above, we can see that the process status for ssh-agent has changed to Zs indicating that the process has become zombie (Z).
Conversely, column eleven has changed to [ssh-agent] <defunct> where the last part indicates that the ssh-agent process is no longer active but remains in the process table.
3.2. Restart the Process
Next, we can proceed to restart the ssh-agent without the need to log out:
$ eval $(ssh-agent -s)
Agent pid 2076389
The eval $(ssh-agent -s) command starts the ssh-agent and configures the shell environment variables. This enables SSH commands to communicate with the agent. Let’s examine the components of the command.
First, the ssh-agent -s command starts the SSH agent in the background and prints out the necessary shell commands to set up the environment variables for interaction with the agent. we can see the exact code by using the command separately:
$ ssh-agent -s
SSH_AUTH_SOCK=/tmp/ssh-E2Q2HJ3zYEjt/agent.574016; export SSH_AUTH_SOCK;
SSH_AGENT_PID=2076389; export SSH_AGENT_PID;
echo Agent pid 2076389;The shell requires the SSH_AUTH_SOCK and SSH_AGENT_PID variables to be properly defined, so it can communicate with the agent and process the process ID of the agent. While the export command makes them available as a child process of the shell, the echo command prints the Agent pid to the terminal.
Lastly, the eval command evaluates and executes the commands generated by ssh-agent -s within the current shell environment.
Now, let’s check the agent process status:
$ ps aux | grep ssh-agent
kali 1415 0.0 0.0 0 0 ? Zs May17 0:01 [ssh-agent] <defunct>
kali 2076389 0.0 0.0 8612 1400 ? Ss 23:37 0:00 ssh-agent -s
kali 2081543 0.0 0.0 6344 2176 pts/0 S+ 23:48 0:00 grep --color=auto ssh-agentThe process table has been updated with the new ssh-agent that we restarted, but now its PID is 2076389. In addition, the process status is again Ss.
4. Restarting ssh-agent: Things to Consider
There are a few drawbacks to be considered when performing a ssh-agent restart without logging out:
- may lose previously loaded keys
- active sessions become unauthenticated
- applications and scripts that depend on the session can break
- environment variable updates required
- increased risk of zombie processes
- security implications
Now, let’s address each of these setbacks and provide technical solutions for all of them.
4.1. Loss of Previously Loaded Keys
As stated, previously loaded SSH keys are lost when ssh-agent is restarted without logging out. So, we usually need to reload the keys into the new ssh-agent instance to avoid a negative impact on ongoing sessions and automated processes.
To do so, we can reload the ssh key back into the ssh-agent instance:
$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/kali/.ssh/id_rsa:
Identity added: /home/kali/.ssh/id_rsa ([email protected])We use the ssh-add ~/.ssh/id_rsa command to add an SSH private key to the ssh-agent for authentication.
Subsequently, the message Identity added confirms that the private SSH key has been successfully imported.
4.2. Active Session Becoming Unauthenticated
Once we reload the SSH key back into the ssh-agent instance, it automatically resolves the issue of an active session becoming unauthenticated:
$ ssh-add ~/.ssh/id_rsaTo clarify, when we restart ssh-agent, active sessions stay unauthenticated until we reload the SSH keys.
4.3. Breaking of Applications and Scripts
Problems with running applications and scripts are usually also solved by reloading the SSH keys but also by updating the environment variables. To that end, let’s combine both the restart and reload using Bash scripting.
To begin with, we create a Bash script:
$ cat ssh_agent_restart.sh
#!/bin/bash
# Kill the existing ssh-agent process
if [ -n "$SSH_AGENT_PID" ]; then
kill $SSH_AGENT_PID
fi
# Start a new ssh-agent
eval $(ssh-agent -s)
# Add SSH key to the new agent
ssh-add ~/.ssh/id_rsa
# Print out the new SSH agent details
echo "ssh-agent restarted."
echo "SSH_AGENT_PID=$SSH_AGENT_PID"
echo "SSH_AUTH_SOCK=$SSH_AUTH_SOCK"In the Bash script above, the if conditional statement checks the status of ssh-agent; if it’s running, then the code within the condition terminates the agent process.
Further, we restart the ssh-agent and reload the SSH key back into the ssh-agent. Notably, we already saw how both of these actions work.
Finally, the last part of the code outputs the updated environment variables to the terminal to verify the results.
Let’s run ssh_agent_restart.sh in the current terminal and observe its output:
$ bash ssh_agent_restart.sh
Agent pid 3272550
Enter passphrase for /home/kali/.ssh/id_rsa:
Identity added: /home/kali/.ssh/id_rsa ([email protected])
ssh-agent restarted.
SSH_AGENT_PID=3272550
SSH_AUTH_SOCK=/tmp/ssh-n9TbADCnQuvF/agent.3272549Thus, the ssh_agent_restart.sh Bash script solves all of the setbacks mentioned earlier, including the two other drawbacks: increasing the risk of zombie processes and security implications.
5. Conclusion
In this article, we practically demonstrated ways to restart ssh-agent, a process that manages SSH keys, without a relogin. Further, we ensured that, unlike the first, the second suggested approach avoids common pitfalls when restarting ssh-agent.
More so, this article delves into various drawbacks of restarting ssh-agent and provides an adequate technical approach to resolve them.