My recent article about reusing
ssh-agent processes attracted a lot of mail, most of it very
Thanks to everyone who wrote in on this matter.
- A number of people missed an important piece of context: since the
article was filed in 'oops' section of my
blog, it was intended as a description of a mistake I had made.
The mistake in this case being to work really hard on the first
solution I thought of, rather than to back up at early signs of
trouble, and scout around for a better and simpler solution. I need
to find a way to point out the "oops" label more clearly, and at the
top of the article instead of at the bottom.
- Several people pointed out other good solutions to my problem. For
example, Adam Sampson and Robert Loomans pointed out that versions of
ssh-agent support a -a option, which orders the process to
use a particular path for its Unix domain socket, rather than making
up a path, as it does by default. You can then use something like
ssh-agent -a $HOME/.ssh/agent when you first start the agent,
and then you always know where to find the socket.
- An even simpler solution is as follows: My principal difficulty was in
determining the correct value for the SSH_AGENT_PID variable.
But it turns out that I don't need this; it is only used for
ssh-agent -k, which kills the existing ssh-agent process.
For authentication, it is only necessary to have
SSH_AUTH_SOCK set. The appropriate value for this variable
is readily determined by scanning /tmp, as I noted in the
original article. Thanks to Aristotle Pagaltzis and Adam Turoff for
pointing this out.
- Several people pointed me to the keychain
project. This program is a front-end to ssh-agent. It contains
functions to check for a running agent, and to start one if there is
none yet, and to save the environment settings to a file, as I did
manually in my article.
- A number of people suggested that I should just run ssh-agent from my
X session manager. This suggests that they did not read the article
carefully; I already do this. Processes running on my home machine,
B, all inherit the ssh-agent settings from the session manager
process. The question is what to do when I remote login from a
different machine, say A, and want the login shell, which was
not started under X, to acquire the same settings.
Other machines trust B, but not A, so credential
forwarding is not the solution here either.
- After extracting the ssh-agent process's file descriptor
table with ls -l /proc/pid/fd, and getting:
lrwx------ 1 mjd users 64 Dec 12 23:34 3 -> socket:
I concluded that the identifying information, 711505562, was useless.
Aaron Crane corrected me on this; you can find it listed in
/proc/net/unix, which gives the pathname in the
% grep 711505562 /proc/net/unix
ce030540: 00000002 00000000 00010000 0001 01 711505562 /tmp/ssh-tNT31655/agent.31655
I had suggested that the kernel probably maintained no direct mapping
from the socket i-number to the filesystem path, and that obtaining
this information would require difficult grovelling of the kernel data
structures. But apparently to whatever extent that is true, it is
irrelevant, since the /proc/net/unix driver has already been
written to do it.
- Saving the socket information in a file solves another problem I
had. Suppose I want some automated process, say the cron job that
makes my offsite network backups, to get access to SSH credentials. I
can store the credentials in an ssh-agent process, and save the
variable settings to a file. The backup process can then reinstate
the settings from the file, and will thenceforward have the
credentials for the remote login.
- Finally, I should add that since implementing this scheme for the
first time on 21 November, I have started exactly zero new ssh-agent
processes, so I consider it a rousing success.
[Other articles in category /Unix]