Consider this case: Alex is sitting at laptop.home , with identity I. He also has a ssh-agent to which he has ssh-added work.key and linux.key He has access to kernel.org, and occasionally he wants to transfer files between kernel.org and linux.org, and thus set up an authorized_keys file on linux.org that trusts linux.key. He also has access to work1.nsa.gov, and occasionally he wants to transfer files between work1.nsa.gov and work2.nsa.gov (for which he uses work.key) However, while he trusts kernel.org's admin not to attempt to hack his way into linux.org, he wouldn't be so sure about him hacking into work1.nsa.gov, so access to work.key should not be given to linux.org. Nor would he trust work1.nsa.gov's admin not to attempt to force his way into kernel.org . So access to linux.key should not be given to work1.nsa.gov With the current ssh-agent and agent-forwarding, there's no way in setting this trust scheme up in a secure way (unless you start multiple ssh-agents, and tweak the SSH_AUTH_SOCK environment variable manually) It would be so much easier if we could say (in laptop.home's ~/.ssh/config file): Host kernel.org.lu ForwardAgent yes ForwardAgentAllowKeysOnly linux.key ... Host work1.nsa.gov ForwardAgent yes ForwardAgentAllowKeysOnly work.key ==> if a ForwardAgentAllowKeysOnly line is present, the ssh client would only forward requests to one of the listed keys to the agent, and block access attempts to all other keys that the agent may know about, preventing abuse among different unrelated organizations to which user may log in.
Alex could also use ssh-add -c when loading the key to require confirmation at the time of use.
Two problems with this work-around: 1. What if Alex started a long-running script needing ssh access, and went for a coffee? 2. The askpass prompt doesn't actually say which session requested access to the key. So an attacker could still abuse keys not intended for him by just timing his request right.
the ssh-agent-filter program[1] would make the workaround you suggested yourself (start multiple ssh-agents, and tweak the SSH_AUTH_SOCK environment variable manually) a little less cumbersome, as only one real agent would be involved. if bug #2216 was solved, would those two things constitute a viable solution for this bug? [1] https://github.com/tiwe-de/ssh-agent-filter
Looks like this is implemented with IdentitiesOnly
I agree; moreover, the bug #2216 I linked in my last comment is immaterial to this particular use case.
Created attachment 3087 [details] prefer to forward SSH_AUTH_SOCK_FORWARD if present This makes ssh prefer to forward the agent socket pointed to by $SSH_AUTH_SOCK_FORWARD if it is set. If it is not set, then SSH_AUTH_SOCK is used as usual.
Move to OpenSSH 7.8 tracking bug
There are other proposals for agent filtering, including https://github.com/StanfordSNR/guardian-agent and others. Removing release target until we have a better plan.