I'm using keychain, which manages my key(s) with ssh-agent perfectly.
I want to check the state of ssh-agent on each linux host. I tried with :
ssh-add -l
1024 f7:51:28:ea:98:45:XX:XX:XX:XX:XX:XX /root/.ssh/id_rsa (RSA)
Locally, this command works and is coherent.
But with a distant SSH command, I don't know why the result is not the same.. :
## host1, locally
ssh-add -l
1024 f7:51:28:ea:98:45:XX:XX:XX:XX:XX:XX /root/.ssh/id_rsa (RSA)
## host 2, command to host1 :
ssh host1 "ssh-add -l"
Could not open a connection to your authentication agent.
Maybe someone could explain me ? It't disturbing, because I would to monitor ssh-agent states..
Thanks.
EDIT : Even with SSH Agent Forwarding enabled, the distant command returns only the local state of agent. Other distant commands works, with or without key loaded..
## Host1, locally
ssh-add -l
1024 f7:51:28:ea:98:45:XX:XX:XX:XX:XX:XX /root/.ssh/id_rsa (RSA)
## From Host2, locally and distant :
ssh-add -l
The agent has no identities.
ssh -A host1 "ssh-add -l"
The agent has no identities.
You seem to misunderstand how keychain/ssh-agent work. When you log onto a system (we'll call it 'home'), it starts a program. As part of starting this program it exposes a file that ssh-add can connect to. When the name of this file is stored in the SSH_AUTH_SOCK variable, it becomes accessible by ssh and by ssh-add when run with this enviroment variable set appropriately.
When you ssh to a remote system, if the ForwardAgent property is set to true in your configuration, a channel is established allowing this key information to pass from your 'home' system to the system that you've ssh'd to. In order to expose this key information, another SSH_AUTH_SOCK variable is set on this remote system. So now we have:
# home system (host1)
host1$ ssh-add -l
1024 BLAH....
host1$ echo $SSH_AUTH_SOCK
/tmp/ssh-YJNLu2LFMKbO/agent.1472
home$ ssh -A host2
host2$ ssh-add -l
1024 BLAH
host2$ echo $SSH_AUTH_SOCK
/tmp/ssh-vqdu733feY/agent.23877
host2$ ssh -A host1
host1$ ssh-add -l
1024 BLAH
host1$ echo $SSH_AUTH_SOCK
/tmp/ssh-fuKgOaaQ7b/agent.23951
so with every connection, a socket is created on the remote system to ferry the key data through the chain to the original 'home' system. So in this example:
ssh-agent(on host1) makes a SOCKET -> ssh(host2) [provides a SOCKET connecting back to the SOCKET on host1] -> ssh(host1) [provides a SOCKET connecting back to the socket on host2]
So ssh, once you connect to the remote system is providing a socket that connects back to the socket from the system that it came from.
If you log on to a system directly (e.g. logging onto host2 at the console), then there is absolutely no connection back to host1. If an agent is started on host2, then it provides it's own, private socket, that you are communicating with.
Where things can go wrong:
You've enabled agent forwarding on your connection from host1 -> host2; however the script that runs at login on host2 ignores the presence of this socket and starts it's own private agent on host2. As a result when you ask for lists of registered keys using ssh-add -l, it talks to the socket provided by the agent running on host2. This agent does not have access to the keys from host1 as it ignored the socket.
agent forwarding can be disabled by the sshd_config, which means that the server administrator has configured the system to prevent people forwarding their agent information into this system (if there's an AllowAgentForwarding no line in the sshd_config then this would be the case).
The first case would be when there is a badly written login script that ignores the presence of the variable - i.e. it doesn't properly detect the fact that the connection is remote and there is a socket being forwarded - this is rare, but can happen. If it does then the script would need to be rewritten to detect this case.
If the administrator of the remote system has disabled agent forwarding, then you need to ask for it to be enabled.