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_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.