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 auth-agent-req@openssh.com 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 auth-agent-req@openssh.com

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

debug1: Requesting authentication agent forwarding.
debug2: channel 0: request auth-agent-req@openssh.com 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 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 at 1:29

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.