openssh bugs - Sep 2011 - [Bug 1937] New: Make it possible to give a give an ssh session only access to a limit subset of ssh-agent keys

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

             Bug #: 1937
           Summary: Make it possible to give a give an ssh session only
                    access to a limit subset of ssh-agent keys
    Classification: Unclassified
           Product: Portable OpenSSH
           Version: 5.8p1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: ssh
        AssignedTo: unassigned-bugs at mindrot.org
        ReportedBy: mindrot2 at misc.lka.org.lu


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.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #1 from Darren Tucker <dtucker at zip.com.au> 2011-09-12
10:29:23 EST ---
Alex could also use ssh-add -c when loading the key to require
confirmation at the time of use.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

--- Comment #2 from Alain Knaff <mindrot2 at misc.lka.org.lu> 2011-09-12
18:45:21 EST ---
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.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.