Proposal: always handle keys in separate process

[Alexander Wuerstlein]

Hello,

in light of the recent CVE-2016-0777, I came up with the following idea,
that would have lessened its impact. Feel free to ignore or flame me,
maybe its stupid or I missed something :)

- private key material should only ever be handled in a separate process
  from the SSH client. ssh-agent (maybe slightly extended) seems the
  logical choice.
- in places where the client currently reads ssh-keys
  (load_public_identity_files), automatically spawn an ssh-agent instead
  if none is available. Connection to the agent might be via the usual
  SSH_AUTH_SOCK or via an inherited pipe() or socketpair() if newly
  spawned. Those anonymous filedescriptors would mean that this
  ssh-agent is 'private' to this one client.

Where I'm not quite sure how to handle things would be:
- If a ssh-agent is already running, but the client needs to read more
  keys: Spawn and handle a second, private agent? Use ssh-add? The
  former would be preferable but more complicated because two different
  agents would have to be handled. The latter would have the unwanted
  side-effect of exposing keys via the ssh-agent that maybe shouldn't
  be.
- If a key is password-protected, the client would have to read the
  password and pass it on to ssh-agent. Could this be done in a better
  way, maybe without exposing the password to the ssh-client?

This would mean that:
- ssh client could be stripped of any code that reads ssh-keys directly.
- or using the mechanism above could be made an option SpawnPrivateAgent
  (possibly defaulting to 'yes')
- maybe, if that works, one could do a similar thing for sshd and its
  hostkeys.



Ciao,

Alexander Wuerstlein.