45

Let's say I have a key for Github, along with other keys. I've added lots of keys to my ssh agent (ssh-add -L returns lots of lines) at my home computer A. In my .ssh/config I have set up which key to use with which host, so e.g.

ssh -T -vvv git@github.com 2>&1 | grep Offering

gives

debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.github

Only one key is offered, as expected. But then ssh-ing to some host B with ForwardAgent yes and repeating the same command, I get

debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.linode2
debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.helium
debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.github

meaning it tries all my keys. This is problematic since only a limited number of keys can be tried before servers return Too many authentication failures. So I tried editing .ssh/config on host B to include

Host github.com
  IdentityFile /Users/doxna/.ssh/id_rsa.github
  IdentitiesOnly yes

but then I get no key offerings, but rather

debug2: key: /Users/doxna/.ssh/id_rsa.github ((nil))

which I guess means that the key was not found(?) And after all, the key is located at my home computer A, not host B, so the question is how to refer to it at host B? Hope I managed to explain the question.

danmichaelo
  • 552
  • 1
  • 4
  • 8

2 Answers2

39

You got the right idea. The only part you are missing is that the file pointed to by IdentityFile must exist. It does not need to contain a private key, having just the public key available is sufficient.

On host B you can extract the public key from the agent by typing ssh-add -L | grep /Users/doxna/.ssh/id_rsa.github > ~/.ssh/id_rsa.github.pub and then point to that file from ~/.ssh/config

kasperd
  • 29,894
  • 16
  • 72
  • 122
  • 1
    FYI the public key name does not matter. It will select proper key from agent based on content. – akostadinov Nov 25 '16 at 20:35
  • @akostadinov True. If you point `ssh` to a public key file with no associated private key file, it should just read the public key from the file and have the agent use the corresponding private key to generate the signature. – kasperd Nov 25 '16 at 20:49
  • This effectively saves your key on host B! See answer below by @mc0e for a solution that does not save the key on the server. – Pitt Jul 19 '17 at 18:47
  • 7
    @Pitt No it doesn't. It only stores the **public** key. And that is not a problem as the public key was never expected to be kept secret in the first place. Agent forwarding gives the host access to use the key as long as the agent forwarding is in place, but the agent will never send the secret key anywhere. – kasperd Jul 19 '17 at 19:27
  • @kasperd you don't need an actual copy of the private key while you have a live connection to a user agent with the key. As root you can access the agent connections of other logged in users. – mc0e Mar 03 '18 at 10:45
  • @mc0e That is true. You shouldn't forward your agent to hosts you don't trust. But your private key is still much better protected with agent forwarding than it is if you copy it to the host. Also you can configure it such that using a key from the agent requires confirmation. – kasperd Mar 21 '18 at 19:42
5

Nice answer from @Kasperd, but note also that if Host B is compromised, or if you don't trust all those with root privileges there, then you're still exposing all of your keys to abuse for as long as you're logged in on that host.

So a better approach might be to only forward access to the keys you need. Maybe try ssh-agent-filter which is in debian / Ubuntu repositories, or from github.

EDIT: I've settled on ssh-ident rather than ssh-agent-filter for forwarding keys selectively, though it's not as smooth an experience as one might hope for.

mc0e
  • 5,786
  • 17
  • 31
  • 1
    From @kasperd's comment on his answer: "it doesn't. It only stores the public key. And that is not a problem as the public key was never expected to be kept secret in the first place. Agent forwarding gives the host access to use the key as long as the agent forwarding is in place, but the agent will never send the secret key anywhere" – Bdoserror Mar 02 '18 at 18:28
  • 1
    @Bdoserror As root you can abuse the ssh-agent connection while the associated user is logged in. You just copy the `SSH_*` environment variables and log in to wherever it is you want to go using the key, despite not ever having an actual copy. – mc0e Mar 03 '18 at 10:43
  • 2
    To clarify: this answer is indeed wrong - while the abuse scenario from mc0e is real, it has nothing to do with saving the public key - if the intermediate host is compromised, your agent connection can be used to authenticate with your private key, regardless of whether you save the public key on the intermediate host or not. Your private key wilkl not get compromised, and saving the public key will not make it easier, as any attacker who has a connection to the agent can just ask it for the public keys anyway. – Remember Monica Jul 27 '19 at 16:43
  • @marc-lehmann reread what I wrote. If you forward keys then they will be exposed, but you can limit which keys get forwarded. – mc0e Jul 29 '19 at 01:24
  • 1
    I tread what you wrote - please address the substance of our comments, not the person. The problem is that your answer is simply wrong because it assumes, as you write, that keys "are forwarded" to the remote host. No such thing happens, and the keys themselves are not exposed. – Remember Monica Aug 13 '19 at 05:15
  • @marc-lehmann I've made a correction. It's access to the use of the keys that is forwarded, not the keys themselves. The main pont of my answer stands though - i.e. "you're still exposing all of your keys to abuse for as long as you're logged in on that host" – mc0e Aug 29 '19 at 12:49