I am struggling to diagnose why one particular server does not honour the agent forwarding I have setup.

From client (macOS) I can ssh -A to any number of servers and on them can see that SSH_AUTH_SOCK is set, and ssh-add -L shows my key.

On one particular host this does not work. When I login SSH_AUTH_SOCK is set, but ssh-add -L says "this agent has no identities."

Firstly my sense is that if SSH_AUTH_SOCK is set then the agent forwarding has worked in the sense that AllowAgentForwarding is enabled on client and server (which I've checked to be true).

For example:

On the problematic host:


$ ssh-add -l
This agent has no identities.

And for the ssh server on that host I find these mentions of 'agent' in the sshd logs when DEBUG3 is set:

Jul  4 xxxxxxx hostname sshd[14924]: debug1: server_input_channel_req: channel 0 request [email protected] reply 0
Jul  4 xxxxxxx hostname sshd[14924]: debug1: session_by_channel: session 0 channel 0
Jul  4 xxxxxxx hostname sshd[14924]: debug1: session_input_channel_req: session 0 req [email protected]

Correspondingly on the client (macOS), I see this with ssh -vvv hostname:

debug1: Requesting authentication agent forwarding.
debug2: channel 0: request [email protected] confirm 0
debug3: send packet: type 98

So that covers all the options and scenarios my knowledge of ssh and its config comprise. So I am asking what further steps I might do to source the problem, or what I'm missing more obviously.



  • On the problematic machine, are you logging into an existing screen or tmux session, or is the variable set by the user's shell's startup files?
    – Kusalananda
    Jul 4, 2019 at 11:26
  • I am not using screen or tmux sessions. From the client terminal I am simply issuing ssh -A <hostname>. I am not explicitly setting any variable. SSH_AUTH_SOCK is set by ssh by dint of using -A (agent forwarding).
    – r.l.
    Jul 5, 2019 at 1:29

1 Answer 1


The comment from Kusalananda was useful - pointed me toward checking things. Contrary to my thoughts, I did have 'eval $(ssh-agent)' in $HOME/.bash_profile of the problematic server. I just didn't think to check that. That obviously overwrote the socket. Reason was that server was historically used as a source for connections to other servers and at that time I used an agent on it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .