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:
>
>https://blog.affien.com/archives/2015/09/07/use-macports-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).

R.

Reply via email to