Re: [Sshmgmt] Agent forwarding

Almost all non-interactive use of SSH is without using an agent (though I am aware of some cases where people load a key with a passphrase into an agent in a script and use it through the agent).  Thus I see agent forwarding primarily as an issue for interactive use.

I agree with Peter that limiting agent forwarding is kind of difficult to deal with making the non-SSO usage more difficult.  I believe at least OpenSSH disables agent forwarding by default, and my understanding is that Tectia SSH has provided the ability to gain visibility to what is done with the agent and restrict it for years (at least on Windows platforms).  

Overall, I see this as a user interface issue for clients, rather than a protocol issue or even an issue to be addressed in the key management draft (the main substance of the draft is around provisioning and managing access to systems using SSH keys throughout the lifetime of such access).

I could of course add some language about agent and the use case I mentioned in the first paragraph in Section 2, but my preference would be to keep Section 2 as short as possible, because the lead-in to the real substance in Sections 3-7 is already a bit lengthy (but needed in my opinion as many people are not so familiar with how authentication in SSH actually works - I also considered moving some or all of Section 2 to an appendix but in the end decided to leave the material where it is but try to keep it reasonably short).

Tatu

On Apr 20, 2013, at 3:23 PM, <peter@notatla.org.uk> <peter@notatla.org.uk> wrote:

> Simon Josefsson writes:
>> Briefly, if a remote system has been compromised, and you connect to it
>> using 'ssh -A', the remote system can use your credentials to login to
>> other systems.  Normally there is no user feedback of what is going on
>> either.  I've seen uses of 'ForwardAgent yes' in people's .ssh/config
>> which is risky and IMHO a problem worthy of attention.
> 
> This is a risk but it's difficult to deal with without removing the
> non-interactive SSO that the agent provides and is the reason people
> use it.
> 
> Also from the man page: "Several identities can be stored in the agent;
> the agent can automatically use any of these identities."
> 
> What I think could be done are:
> 
> a) logging by the agent when it computes a challenge
> 
>   The log to include the host public key which the
>   challenge proves correct and fresh.  I'm guessing that's
>   possible (even if it meant reworking the challenge)
>   but haven't studied it.  The aim is that when you are
>   blamed for a login you show in the agent log how it was
>   assisted by the agent during contact with some other
>   list of hosts - one of which is now suspected of using
>   the agent without user consent.
> 
> b) real-time display by the agent when it computes a challenge
> 
> c) limit the agent instance by number/rate of challenges
> 
> d) limit the agent instance by which hosts/identities it will
>   compute challenges for (again assuming it knows which that is).
> _______________________________________________
> sshmgmt mailing list
> sshmgmt@ietf.org
> https://www.ietf.org/mailman/listinfo/sshmgmt