This is what I would assume, but has it been confirmed that this vulnerability doesn't affect identities provided by an SSH agent? If any of this "roaming" support was provided by the agent, it could be the case that the leakage can be triggered via SSH agent protocol requests. I doubt this is the case but I don't see anything confirming or denying it.
It would be nice to hear some official word on whether agent-based authentication is vulnerable, because if it isn't, the seriousness to me is greatly reduced, as I never load identities in the client directly.
https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-077...
Quoting from above: Finally, for these three reasons, passphrase-encrypted SSH keys are leaked in their encrypted form, but an attacker may attempt to crack the passphrase offline. On the other hand, SSH keys that are available only through an authentication agent are never leaked, in any form.
So if you use an agent, and follow the good advice to encrypt your private keys you should be safe(er).
See for older client versions:
http://martin.kleppmann.com/2013/05/24/improving-security-of...
or better for newer clients:
http://www.tedunangst.com/flak/post/new-openssh-key-format-a...
https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-077...
This means they are basically able to dump the memory of just the running `ssh` process -- eerily similar to Heartbleed.
This means private keys stored by the `ssh-agent` process, outside of the `ssh` process connecting to an Evil Server(TM) are not affected.
This is because the protocol used between SSH Agent and SSH client does not transfer the entire private key, rather the SSH client asks the Agent to do a signing operation on it's behalf.
A better mandate would be to use ssh-agent. Using separate key pairs without an agent doesn't prevent key theft due to memory disclosure vulnerabilities like this one; it merely compartmentalizes the damage. But if you use an agent, the client never loads the private key, so it's safe from memory disclosure vulnerabilities. Stealing a private key would require filesystem access or remote code execution, at which point all of your private keys are at risk, so you might as well just use a single private key per device.
For the best security, store your private key on a smartcard, so even an attacker with filesystem access or remote code execution can't steal it.