I've realized over the past few months that the ssh's command flag "-i" (which refers to specify an identity file) doesn't work properly when I try to authenticate to some server.

From what I understood, I could use this flag to specify an ssh key to authenticate to the server, avoiding the need to test over each key added to my agent and possibly overflow the connection attempts.

What I'm trying now is to change the user to authenticate to git (the question is not git specific), and what is happening is this:

  • I have two ssh keys that authenticate to github, let's call them user1.pem and user2.pem.
  • user1.pem authenticates to user1 in github and user2.pem authenticates to user2.
  • I run the command "ssh -T [email protected]", it authenticates to user1.
  • I run the command "ssh -T -i ~/.ssh/user2.pem [email protected]", it continues to authenticate to user1.

There's no problem at all with the keys, both have been added to the agent and they have the correct file permissions.
To circumvent this I had to remove all the keys from my agent and re-add only the user2.pem, then it authenticated to user2.

Just to reiterate, this is NOT git specific, as I had this problem with common linux servers as well, and I couldn't find any solution besides configuring the hosts in the ~/.ssh/config file. I'm using git as example just because it is easier to test.

Am I using "ssh -i" flag in the wrong way?

  • If you use ssh ... [email protected], it authenticates as user git, not as user user1. Jul 22, 2020 at 15:15
  • You are correct, I authenticate as user 'git' regarding the server user, but the identity I'm sending is not the one being used. I've just expressed myself badly, but I will fix it using another server example that I have. The problem is with the "ssh -i" command itself, not with server-side users, but I will fix the question.
    – Teodoro
    Jul 22, 2020 at 15:34

1 Answer 1


From the descrition of your problem, this is related to (the absence of) this option seen in man ssh_config:


Specifies that ssh(1) should only use the authentication identity and certificate files explicitly configured in the ssh_config files or passed on the ssh(1) command-line, even if ssh-agent(1) or a PKCS11Provider offers more identities. The argument to this keyword must be yes or no (the default). This option is intended for situations where ssh-agent offers many different identities.

You are also probably enabling the AddKeysToAgent option (which is handy) which will automatically keep user1 loaded in the agent after first use.

So you should run this:

ssh -T -o IdentitiesOnly=yes -i ~/.ssh/user2.pem [email protected]

This will prevent the identity for user1 to be ever considered for authentication and force the use of the identity for user2.

Alternately (but not so useful) unsetting the environment variable SSH_AUTH_SOCK will render the ssh agent unavailable to the command. This would have a similar result, except you'd be asked each time the passphrase again instead of the agent providing the decrypted key itself in the former case once loaded.

  • Yes! This worked perfectly. Thank you. Incredible how there's absolutely no reference to this config option being necessary in order to -i option perform an exclusive authentication attempt with the provided key. Now I'm aware of these options and how they might be needed to work together with the options.
    – Teodoro
    Jul 22, 2020 at 17:33
  • Probably because it's rare to own two private keys both able to authenticate to the same place (even if for github it ends up not really being the same place). Usually the first fails, then the 2nd is tried.
    – A.B
    Jul 22, 2020 at 17:35
  • In my case this happens because I have my computer both for personal and professional use. I have my keys to authenticate to my personal Github but now I had to use different keys to authenticate to a client's account and have access to a private repository of them. I could just send them my already generated public key but this problem was bugging me a lot and I wanted to investigate it before going to the easy (and more reliable) solution.
    – Teodoro
    Jul 22, 2020 at 17:39
  • 1
    But something related happened a while ago.. I had too many keys added to my agent and I was getting a "too many attempts" error when trying to log into a server. I tried this "ssh -i " command to avoid all the useless attempts but it didn't work. Now I know why.
    – Teodoro
    Jul 22, 2020 at 17:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .