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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
