I've noticed that the ssh-agent applies any keys it already has passwords for (via ssh-add) first, overriding the ssh config files for preferred identity file from .ssh/config and -i. This seems a documented behavior. However, this causes problems with some tool chains that use the authorized_keys command directive to change behavior based on which key is used. In my case, I use gitolite for git repositories, and we have a number of developers, each with different permissions. As the admin, I have more than one SSH identity that gives me different permissions on the server (again, through a command directive on authorized_keys on the server). So, my .ssh/config uses two different Host configs, so I can use the alias hostname to get to the different access permissions: Host=hostA Hostname=repos.example.com IdentityFile=usera Host=hostAAdmin Hostname=repos.example.com IdentityFile=userb Of course, these key files are password protected. Once ssh-agent has the usera or userb key installed, it ignores the config...meaning I have to do a lot of shuffling with ssh-add...and I've lost the benefit of using ssh-agent at all...worse, now I'm typing ssh-add -D, followed by ssh-add identity, followed by the password again! I just end up killing ssh-agent and typing passwords....unless I'm on OSX, which auto-starts ssh-agent every time I use ssh. This seems incorrect, since I would not have configured IdentityFile if it didn't matter to me. I would consider this a bug, though I know it is a documented "feature"...which is why I'm writing here. Please enlighten me. Tony
On 12/13/2011 05:52 PM, Tony Kay wrote:> Host=hostAAdmin > Hostname=repos.example.com > IdentityFile=userb > > Of course, these key files are password protected.Have you tried setting IdentityFile to userb.pub instead of userb and loading userb into the agent? The .pub files (containing only the public key) will not be password-protected. I was told by a colleague that specifying the .pub form let her ssh client prioritize which of the several keys she had loaded into her agent she would offer to the server first. I haven't had a chance to test it myself yet, nor do i remember what version of OpenSSH my colleague was using. If it works for you (or doesn't), please report back! hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111214/fe2c55c1/attachment.bin>
On 13/12/11 23:52, Tony Kay wrote:> Once ssh-agent has the usera or userb key installed, it ignores the > config...meaning I have to do a lot of shuffling with ssh-add...and > I've lost the benefit of using ssh-agent at all...worse, now I'm > typing ssh-add -D, followed by ssh-add identity, followed by the > password again! I just end up killing ssh-agent and typing > passwords....unless I'm on OSX, which auto-starts ssh-agent every time > I use ssh.You could do SSH_AUTH_SOCK= ssh hostAAdmin You would be effectively disabling the ssh agent (by emptying the SSH_AUTH_SOCK env var to the child ssh process), which means that you will need to enter the password manually. Still, seems better than the current approach. A more advanced approach would be to have two ssh agents on different sockets, and switch among them, playing or perhaps with wrappers, or having SSH_AUTH_SOCK point to a symlink that you repoint to one or another as you change hats. I know it doesn't solve the underlying problem (yes, it looks like a bug), but hopefully it can make your life a bit easier.
On 2011-12-13 at 14:52 -0800, Tony Kay wrote:> I've noticed that the ssh-agent applies any keys it already has > passwords for (via ssh-add) first, overriding the ssh config files for > preferred identity file from .ssh/config and -i. This seems a > documented behavior.ssh_config(5): IdentitiesOnly Specifies that ssh(1) should only use the authentication identity files configured in the ssh_config files, even if ssh-agent(1) offers more identities. The argument to this keyword must be ``yes'' or ``no''. This option is intended for situations where ssh-agent offers many different identities. The default is ``no''.