As Patrick points out, it's likely that your ssh-agent
competes with an instance spawned by your desktop environment. Well, competing is probably not the right word - the variables allowing other applications to talk to the agent must be in their environment. Since all applications in your desktop sessoin are spawned in some way by some part of the desktop environment (lets assume it is the session manager) you first need to get the variables into the environment list of the session manager. This can happen in two ways:
the session manager does it internally (depending on some option you set somewhere). This would include the agent being spawned by a PAM module (called from login/session manager).
through a user script like yours. However, this is not as straightforward as it might seem. When the session manager runs your script, it creates a new process - the script interpreter. In its environment the variables are set, but can't be easily exported back into the session manager - its parent process. This is equivalent to doing the same in your shell - running the script will have no effect whatsoever on the environment of the current shell. You'd have to source
it - then the commands would be executed by the current shell thus giving you access to the updated/created variables. This would be rather complicated to do in the session manager (since it it not a shell interpreter). Thus your ssh-agent
is not really competing. It just sits there with identities loaded by ssh-add
from your script and no-one really knows about it.
To get some idea of what is going on check the output of1
ps fax | grep -E "(ssh|gpg)-[a]gent"
and change your script to
echo "SSH_AUTH_SOCK=$SSH_AUTH_SOCK" > ~/ssh-agent.stdout
echo "SSH_AGENT_PID=$SSH_AGENT_PID" >> ~/ssh-agent.stdout
eval `ssh-agent | tee -a ~/ssh-agent.stdout`
This will print the content of the variables into the file ~/ssh-agent.stdout
and then add the output from ssh-agent
at that very place before processing it (and thus exporting the variables). Compare content of the file with the the environment variables SSH_AUTH_SOCK
and SSH_AGENT_PID
for example in a freshly created shell terminal. In most cases you'll be able to tell which one was started first since the PIDs are (cyclically) monotonously growing. The gpg-agent
part is there because some DEs use the ability of gpg-agent
to provide SSH agent services as well.
You may also remove that line calling ssh-agent
completely - if your script is being run after the SSH agent spawned your desktop environment you'll get the password dialog (for the right agent by the way), since the environment variables will be present. If not, it means your script is being run before the DE's agent instance and thus has no access to any agent at all.
1 the brackets are a neat trick to remove the grep
itself from the process list.
ssh-agent
isn't being replaced. Many desktop managers will launchssh-agent
automatically, thus replacing the environment variables set by the previous one. Also, how are you launchingssh-agent
? Most of the time, if you want this to work, it has to be launched before the desktop manager starts so the variables are inherited.