vulnerability with ssh-agent

[Keld Jørn Simonsen]

Hi

I have written a small introduction to newbies in Danish on ssh and
friends. Now some people are questioning my advice and I think they have
a point.

I am advocating people to use DSA-keys and a config file with this:

   Protocol 2
   ForwardAgent yes
   ForwardX11 yes
   Compression yes
   CompressionLevel 9

and running ssh-agent and ssh-add, and then loggin in without giving
keys.

One commenter said that this has big holes. An intruder with root
privileges could set SSH_AUTH_SOCKET to at socket for ssh-agent found in
/tmp, and he could also find the keys in the /proc area for the
ssh-agent.

Is that true?
Are the keys visible under Linux in the /proc memory mapping for ssh-agent?

Could there be done something to better these vulnerabilities?

I was thinking along the lines of deleting the socket in temp, if an
option "delete_ssk_auth_socket" was given in config, and then only
processes that inherited the socket via fork() would have access to the
socket, via an open file descriptor. An intruder would then need to
program opening of an inode that was deleted, which is much harder than
just using readily available ssh with an easy-to-find SSH_AUTH_SOCKET.
This would work fine in the standard setup, where ssh-agent is launched
as part of the initiation of X. 

If forwardagent is on would there be keys stored in the memory on the
machine logged in to (thus findable in /proc), or will ssh-agent there always 
refer back to the machine logged in from?

Would there be a way for ssh-agent to have the keys stored in memory, so
that is not easily found in /proc?

Best regards
Keld Simonsen