ssh-agent use in different security domains

[Damien Miller]

On Tue, 25 Oct 2011, Saku Ytti wrote:

> Consider this topology
> 
>                 domain1-server1      domain2-server2
>                             |                             |
>     laptop - domain1-server1 ---- domain2-server1
> 
> 
> Laptop has two ssh identities, domain1 and domain2.
> 
> 
> I don't wish to store identity locally in any of the servers. As far
> as I understand, there isn't any way to limit ssh-agent to allow only
> signing domain2 servers with domain2 identity? So Evil Admin of
> domain2 could potentially ssh using my domain1 identity to domain1
> server?
> 
> 
> But need this be so? Couldn't we have something like
> 
> cat >> .ssh/config
> host *.domain1.*
>   Identity permit domain1-key
>   Identity deny all
> 
> host *.domain2.*
>   Identity permit domain2-key
>   Identity deny all
> ^D
> 
> Or maybe ssh-agent itself could prompt user: 'domain2-server2 wants me
> to sign with identity domain1-key, allow? yes/no, [ ] always?'.
> 
> Or is this problem already solved somehow?

It is always safe to attempt to authenticate to a server with an agent-
hosted key - a hostile SSH v.2 server _cannot_ replay your authentication
to another host. The risk comes in when your _forward_ your agent to a
potentially-untrustworthy server. If you aren't forwarding your agent
then you don't need to worry.

If you are forwarding your agent, then right now we don't have any way to
limit key visibility. To do this we'd need to either build it into
ssh-agent or into ssh itself. Neither is particularly desirable -
ssh-agent is intended to emulate a hardware cryptographic token: you can
put your keys in and use them to sign, but not get them out easily. Each
extra line of code in ssh-agent adds attack surface that makes key
extraction more likely.

Putting key scoping in ssh is a little better, but a fair bit more work.
Right now, ssh has the luxury of treating agent connections as dumb,
opaque pipes. If it is to perform scoping, then it must instead proxy
agent connections, which requires it to speak the entirety of the agent
protocol which would add quite a bit of code to ssh. This could be
alleviated somewhat if the agent code were in a library that is shared
by ssh-add / ssh and possible ssh-agent - I've made a small start towards
this on the plane back from EuroBSDCon, but it will be a while before it
is ready.

-d