53

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 [email protected] 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.

Improve this question

2 Answers 2

Reset to default
47

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

Improve this answer
7
  • 1
    FYI the public key name does not matter. It will select proper key from agent based on content. Commented Nov 25, 2016 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. Commented Nov 25, 2016 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. Commented Jul 19, 2017 at 18:47
  • 9
    @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. Commented Jul 19, 2017 at 19:27
  • 4
    This trick does not work (suppliing the public key as argument to IdentityFile) in openssh 8.7, it errors with "error in libcrypto". There is probably another way to choose the agent key. Commented Sep 11, 2023 at 11:45
7

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.

Improve this answer
6
  • 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" Commented Mar 2, 2018 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. Commented Mar 3, 2018 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. Commented Jul 27, 2019 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. Commented Jul 29, 2019 at 1: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. Commented Aug 13, 2019 at 5:15

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.