As mentioned, -v
(or -vv
) helps to analyze the situation.
My theory is that you already have something providing ssh agent service, but that process is somehow stuck, and when ssh tries to connect it, it doesn't respond to the connect, or it accepts the connection but doesn't actually interact with ssh. Quite possibly ssh doesn't have a timeout for interacting with ssh-agent.
Using eval $(ssh-agent -s)
starts a new ssh agent and replaces the environment variables in question with the new ones, therefore avoiding the use of the stuck process.
If this is the actual problem here, then before running the eval
, echo $SSH_AUTH_SOCK
would show the path of the existing ssh agent socket. If this is the case, then you can use lsof $SSH_AUTH_SOCK
to see what that process is. Quite possibly it's provided by gnome-keyring-daemon
if you're running Gnome. As to why that process would not be working I don't have ideas.
Another way to analyze the problem is strace -o logfile -f ssh ..
and then check out what is at the end of the logfile
. If the theory applies, then it would likely be a connect
call for the ssh-agent.
Where should they be "taking" funding instead?