On Sat, May 30, 2015 at 2:41 PM, Peter Stuge <peter@xxxxxxxx> 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@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
