Bug 1937

Summary:

Make it possible to give a give an ssh session only access to a limit subset of ssh-agent keys

Product:

Portable OpenSSH

Reporter:

Alain Knaff <mindrot2>

Component:

ssh

Assignee:

Damien Miller <djm>

Status:

NEW ---

Severity:

enhancement

CC:

chrysn, daniel, djm, dtucker, jasper, mindrot

Priority:

Version:

5.8p1

Hardware:

All

OS:

All

See Also:

https://bugzilla.mindrot.org/show_bug.cgi?id=2216

Attachments:

Description	Flags
prefer to forward SSH_AUTH_SOCK_FORWARD if present	none

Description Alain Knaff 2011-09-12 05:44:15 AEST

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.

Comment 1 Darren Tucker 2011-09-12 10:29:23 AEST

Alex could also use ssh-add -c when loading the key to require confirmation at the time of use.

Comment 2 Alain Knaff 2011-09-12 18:45:21 AEST

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.

Comment 3 chrysn 2014-03-25 02:36:27 AEDT

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

Comment 4 Daniel Black 2017-11-08 13:34:03 AEDT

Looks like this is implemented with IdentitiesOnly

Comment 5 chrysn 2017-11-08 21:03:37 AEDT

I agree; moreover, the bug #2216 I linked in my last comment is immaterial to this particular use case.

Comment 6 Damien Miller 2017-11-10 13:27:43 AEDT

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.

Comment 7 Damien Miller 2018-04-06 13:12:21 AEST

Move to OpenSSH 7.8 tracking bug

Comment 8 Damien Miller 2018-06-08 13:43:32 AEST

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.