Using two agents

[Ángel González]

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.