ssh-add: local private keys added to forwarded agents

Nicolas.Williams at ubsw.com Nicolas.Williams at ubsw.com
Thu Jun 6 00:58:37 EST 2002


The behaviour you describe does not violate the [draft] specification. Clearly, many (most!) SSH users do not store keys in smartcards or any other kind of removable media, and noone claims such behaviour to be in violation of the [draft] spec. Note the word "ideally" in the spec text you quote.

Also, your statement about the agent socket names is incorrect. It is "ls -F" that is adding that '=' to the end of the socket name.

Having said this, I would second any proposal that ssh-add require an additional argument to force the addition of keys to forwarded agents; this would require a mechanism to tell the difference between local and forwarded agents and, in practice, I imagine either a socket naming pattern or an environment variable's setting would be used to tell the difference, though neither approach would be foolproof.

But I am not making such a proposal. I'm big enough to keep track of and know which sessions are which and which sessions have forwarded agents and which don't.

Nico
--  

> -----Original Message-----
> From: Dave Ryan [mailto:dave at ugc.org.uk]
> Sent: Wednesday, June 05, 2002 6:08 AM
> To: openssh-unix-dev at mindrot.org
> Subject: ssh-add: local private keys added to forwarded agents
> 
> 
> Hi,
> 
> This may or may not cause concern for some people 
> (considering a lot of 
> people store all of their keys on a single client system).
> 
> Snippet from draft-ietf-secsh-agent-00.txt:
> 
> 2. Security Considerations
> 
>    This protocol is designed only to run as a channel of the SSH
>    protocol.
> 
>    The goal of this extension is to ensure that the users private keys
>    never leave the machine they are physically at.  Ideally 
> the private
>    keys should be stored on a password protected removable 
> media such as
>    a smartcard.
> 
> I noticed that ssh-add will add a private key to a forwarded agent, if
> there are no local agents started by that user - this breaks the draft
> specification as private keys on a local host are added to an agent 
> running on a remote host. 
> 
> For example,
> 
> USERA starts ssh-agent on HOSTA. USERA then ssh's to HOSTB, USERA then
> runs ssh-add on HOSTB, the private keys from HOSTB are then 
> added to the
> ssh-agent on HOSTA.
> 
> If USERA had started ssh-agent on HOSTB and then ran ssh-add, 
> the keys 
> would have remained on local to the system. 
> 
> I also noticed that if there are no local agents running a 
> remote agent
> socket will show up in /tmp/ssh-XXXXXXXX/ as agent.$PID= whereas if a 
> local agent IS running the "=" is dropped.
> 
> I'm not sure if it is appropriate to apply mechanisms to ssh-add to 
> prevent it adding local keys to a forwarded agent or if a quick 
> addition to the man pages will suffice.
>  
> If this has been discussed before I apologise, couldn't find any 
> references to anything similar.
> 
> Cheers,
> Dave.
> 
> -- 
> ugc Security Research
> http://www.ugc.org.uk/~dave
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.




More information about the openssh-unix-dev mailing list