ssh-agent no longer being started
René J.V. Bertin
rjvbertin at gmail.com
Mon Nov 6 09:49:52 UTC 2017
On Sunday November 05 2017 19:19:55 Kastus Shchuka wrote:
>The Listeners key in ssh-agent plist creates a randomly named socket and exports in SSH_AUTH_SOCK to the user’s shell. It should not be shared with gpg-agent to the best of my knowledge.
gpg-agent is definitely involved though. Its plist attempts to set SSH_AUTH_SOCKET the same way, but using a socket of a slightly different name (Listener_ssh). I can imagine that gpg-agent uses that variable to communicate with SSH for whatever it wants to do with it and indeed if I remove this particular bit from the plist the gpg-agent daemon fails to start correctly. Do we know why gpg-agent wants/needs to be started when someone connects to the Listener_ssh socket and why that socket would need to be exported in the same env. variable as ssh-agent's Listener socket?
Final "proof": I notice that I installed or upgraded the gpg-agent port on Sept. 15th, meaning I didn't reboot or even re-login since that moment and last Friday. I can't remember if or why I used the +ssh_agent variant. I do see the port has gone obsolete so I'll have to update it and see what that changes.
FWIW, I notice that on Linux SSH_AUTH_SOCK points to a socket called `ssh` and that both gpg-agent and ssh-agent are running happily together. Which btw I can also achieve on Mac by starting ssh-agent manually.
>So if SSH_AUTH_SOCK is pointing to an existing file (ls -l $SSH_AUTH_SOCK shows a socket file) can you run "ssh-add -l” ?
I think that some sort of race condition is going on. 2 agents share a socket with the same name but a slightly different file (which is probably irrelevant). Launchd will probably start the agent registered last OR in user (instead of system) space, which leads to gpg-agent instead of ssh-agent .
IOW, unless gpg-agent is set up to take over ssh-agent this situation is bound to lead to errors. Indeed, ssh-add just prints a single word that looks like an internal error code name indicating a failure communicating with the ssh agent. I don't have access to my Mac for a bit, but my guess is it will print that same error when I do `ssh-add -l` instead of `ssh-add -A` .
>I also found this link helpful when I was debugging ssh-agent:
FWIW, starting the system ssh-agent or MacPorts version doesn't make any difference. I did disable MacPorts's ssh-add executable though (that probably means I didn't use the +gsskex variant and that Keychain support actually comes from ssh-add not ssh-agent).
More information about the macports-users