On 31/05/15 03:09, Nico Kadel-Garcia wrote:
My underlying, long-term concern with ssh-agent is my underlying concern with private SSH keys. There's currently no way to enforce secure handling of them on the client side. The almost inevitable result is that people simply use unencrypted private keys, whether or not they're accumulated in an ssh-agent for access to multiple systems. And even intelligent, educated developers and sysadmins copy unencrypted private SSH keys around to remote hosts, wehter or not they are willing to use ssh-agent, because it's simpler.
When you want unattended running over ssh even accross reboots, there's little option than having unprotected keys. I suppose you could have a setgid/setuid ssh-add able to load keys unreadable by the user that will be using that agent. But then it could trick it into loading the key into a fake agent. And if ssh-agent was running as a different user, its own protections won't allow being read by someone else.
There are some helpful stopgaps to unlock and store access to a shareable ssh-agent for unattended system operations, such as using the 'keychain' perl script to configure and access SSH keys for an 'rsnapshot' or similar rsync over SSH based access. But the normal procedure is to not bother, and simply use unencryped private SSH keys.
Does Mac OS keychain provide a more advanced solution? What is your 'keychain perl script' way?
This is, in fact, written into dozens of "chef" and "puppet" system management cookbooks. I've been trying to spend time there trying to provide better handling of private keys, and boy, it's an uphill battle!!!
Think that instead of key files there could be passwords there. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
