On Sat, May 30, 2015 at 2:41 PM, Peter Stuge <peter at stuge.se> wrote:> Nico Kadel-Garcia wrote: >> Mind you, I've never been complete thrilled with ssh-agent. > > Then look into extending it, or writing a new one which does what you > want.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. 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. 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!!!>> If you really want to segregate credentials for different environments > > The agent knows who is asking it about using a key, so you could > certainly have a single agent which applies a policy based on that. > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
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.
On Sun, 31 May 2015, ?ngel Gonz?lez wrote:> When you want unattended running over ssh even accross reboots, > there's little option than having unprotected keys.PKCS#11 token (e.g. a TPM) without a PIN. An attacker might be able to steal use of the key, but they can't steal the key itself. Otherwise, a hardware-free solution is to have an init script start a ssh-agent at boot set to listen on a known socket, add keys to it and then remove the keys from the filesystem. -d