I have been putting my ssh identity files inside my ~/.ssh/ folder. I have probably about 30 files in there.

When I connect to servers, I will specify the identity file to use with something like

ssh -i ~/.ssh/client1-identity [email protected]

However, if I do not specify an identity file, and just use something like this:

ssh [email protected]

I get the error

Too many authentication failures for user123

I understand that is because if no identity file is specified, and ssh can find identity files, then it will try all of them.

I also understand that I can edit the ~/.ssh/config file and specify something like:

Host example.com
PreferredAuthentications keyboard-interactive,password

in order to prevent that connection from trying known identity files.

So, I guess I could move my identity files outside of the ~/.ssh/ directory, or I could specify each host that I want to disable identity-file authentication for in the config file, but is there any way to tell SSH by default not to search for identity files? Or to specify the ones it will search for?

  • 9
    Re "I understand that is because..." - use ssh -v to find out for sure. Commented Apr 9, 2011 at 19:19

9 Answers 9


You can use the IdentitiesOnly=yes option along with IdentityFile (see ssh_config man page). That way, you can specify which file(s) it should look for.

In this example, ssh will only look in the identities given in the ssh_config files + the 4 ones listed on the command line (the identities provided by the agent will be ignored):

ssh -o IdentitiesOnly=yes \
    -o IdentityFile=id1.key \
    -o IdentityFile=id2.key \
    -i id3.key \
    -i id4.key \
    [email protected]

The forms -i and -o IdentityFile= are interchangeable.

In .ssh/config, you can include config like this:

Host example
User user123
Hostname example.com
IdentityFile ~/.ssh/id_rsa_example
IdentityFile ~/.ssh/id_rsa_example2
IdentitiesOnly yes
  • 7
    An example would be nice
    – rubo77
    Commented Aug 14, 2014 at 5:49
  • 6
    @DimitriosMistriotis According to the ssh_config man page, either is acceptable: Configuration options may be separated by whitespace or optional whitespace and exactly one '='; the latter format is useful to avoid the need to quote whitespace when specifying configuration options using the ssh, scp, and sftp -o option. Commented Dec 31, 2016 at 19:30
  • 2
    IdentitiesOnly may not always work, you may have to exclude a host specifically; see superuser.com/questions/859661/… Commented Oct 2, 2019 at 8:39
  • **If your SSH agent is still prompting you for a password, see the answer below.
    – user541686
    Commented May 21, 2020 at 12:43
  • This is counterintuitive. the identity_file man page option should mention that it is possible that the supplied key will not be used at all.
    – Hritik
    Commented Mar 9, 2022 at 18:15

user76528's short answer is correct, but I just had this problem and thought some elaboration would be useful. You might also care about this solution if you've wondered "Why is ssh ignoring my identityfile configuration option"?

Firstly, unlike every other option in ssh_config, ssh does not use the first IdentityFile that it finds. Instead the IdentityFile option adds that file to a list of identities used. You may stack multiple IdentityFile options, and the ssh client will try them all until the server accepts one or rejects the connection.

Second, if you use an ssh-agent, ssh will automatically try to use the keys in the agent, even if you have not specified them with in ssh_config's IdentityFile (or -i) option. This is a common reason you might get the Too many authentication failures for user error. Using the IdentitiesOnly yes option will disable this behavior.

If you ssh as multiple users to multiple systems, I recommend putting IdentitiesOnly yes in your global section of ssh_config, and putting each IdentityFile within the appropriate Host subsections.

  • 12
    nicely explained, thank you. It's not obvious that that parameter 'IdentitiesOnly' means TakeOnlyWhatIExplicitlySpecifyThenFailoverToPassword. And apparently, the ./ssh/id_rsa key is still listed.
    – lImbus
    Commented Jan 9, 2014 at 13:14
  • 6
    Putting IdentitiesOnly yes in the global section of ssh_config is what did it for me. Thanks!
    – jamix
    Commented Mar 20, 2015 at 11:04
  • 3
    Thank you for the detailed comment. I used to use ('\' for newline) Host * \ IdentityFile ~/.ssh/mykey as a configuration option, and at first it seemed odd that having a different entry for a specific site, e.g. Host special \ IdentityFile ~/.ssh/specialkey \ IdentitiesOnly yes continued to supply mykey instead of specialkey. It certainly was unclear, until I realized (from your answer) that the IdentityFile entries are stacked in an order of evaluation and the last-defined one will be used. Removing IdentityFile ~/.ssh/mykey solved the issue, and the correct, single key was used.
    – Ryder
    Commented Oct 5, 2015 at 15:28
  • 3
    Before I tried this, I noticed my git pull/push commands were trying every single identity loaded in my agent. It wasn't a problem till at one point I had too many keys.
    – user351764
    Commented Mar 26, 2018 at 3:06
  • Thank you. Limiting my key to specific hosts rather than the global was the only thing that made ssh use the correct key for me, despite specifying it. It seems the order in which keys are added to the ssh-agent takes precedence over the order of the keyfiles in the ssh config when iterating this stack.
    – Walf
    Commented Nov 16, 2023 at 4:26

I generally do it like so:

$ ssh -o IdentitiesOnly=yes -F /dev/null -i ~/path/to/some_id_rsa [email protected]

The options are as follows:

  • -o IdentitiesOnly=yes - tells SSH to only use keys that are provided via the CLI and none from the $HOME/.ssh or via ssh-agent
  • -F /dev/null - disables the use of $HOME/.ssh/config
  • -i ~/path/to/some_id_rsa - the key that you explicitly want to use for the connection


$ ssh -v -o IdentitiesOnly=yes -F /dev/null -i ~/my_id_rsa [email protected]
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /dev/null
debug1: Connecting to someserver.mydom.com [] port 22.
debug1: Connection established.
debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA f5:60:30:71:8c:a3:da:a3:fe:b1:6d:0b:20:87:23:e1
debug1: Host 'someserver' is known and matches the RSA host key.
debug1: Found key in /Users/sammingolelli/.ssh/known_hosts:103
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to someserver.mydom.com ([]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
Last login: Tue Dec  8 19:03:24 2015 from

Notice in the above output that ssh has only identified the my_id_rsa private key via the CLI and that it uses it to connect to someserver.

Specifically these sections:

debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1


debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
  • 11
    Thanks, this is the only complete solution. Apparently, -F /dev/null is the missing piece in the other answers.
    – leden
    Commented Dec 16, 2016 at 3:36
  • 1
    On Windows the equivalent for /dev/null is NUL. Yes, with only one "L".
    – MMJ
    Commented Oct 8, 2022 at 21:17
  • 1
    Haven't checked when it was added, but there is now the -F none switch to ssh, which should have the effect same or similar to -F /dev/null. Commented Feb 6, 2023 at 15:45

In the scenario where you have many keys, you will invariably run into the "Too many Authentication Failures" error. If you have a password, and want to simply use the password to login, here is how you do it.

To use ONLY password authentication and NOT use Public-key, and NOT use the somewhat misleading "keyboard-interactive" (which is a superset including password), you can do this from the command line:

ssh -o PreferredAuthentications=password [email protected]

Use IdentityFile but Keep Using ssh-agent to Avoid Passphrase Reprompts

The accepted solution of using IdentitiesOnly yes means you'll never be able to take advantage of ssh-agent, resulting in repeated prompts for your passphrase when loading your key.

To keep using ssh-agent and avoid the 'Too many authentication failures' errors, try this:

  1. Remove any interactive console startup scripts that automatically load keys into ssh-agent.

  2. add AddKeysToAgent yes to your client's ssh config. This will prompt you for the passphrase on first connect, but then add the key to your agent.

  3. use ssh-add -D when you get 'too many authentication' errors. This simply 'resets' (deletes) your ssh-agent cache. Then attempt the connection again within the same session. You will be prompted for a passphrase, and once accepted, it will be added to your agent. Since you'll have only one key in your agent, you will be allowed to connect. ssh-agent is then still there for future connections during the same session to avoid reprompts.

    Host ex example.com
       User joe
       HostName example.com
       PreferredAuthentications publickey,password
       IdentityFile /path/to/id_rsa
       AddKeysToAgent yes
  • Will at accept keys added to keychain?
    – vfclists
    Commented Sep 19, 2017 at 13:00

add this at the end of ~/.ssh/config file to prevent use keys for non config servers:

Host *

The ssh client and the ssh-agent is communicating through a Unix domain socket whose name is specified to the client by the SSH_AUTH_SOCK environment variable (set by the agent upon its startup).

Thus, to prevent a single invocation of the client from querying the agent this variable can be set explicitly to something invalid, like an empty string;

$ SSH_AUTH_SOCK= ssh user@server

A client invocation like this will fail communicating with the agent and only be able to offer the identities available as files in ~/.ssh/, or any specified on the command line using -i, to the server.

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused
  • 1
    This is a great answer. It's simple and works when you're using commands that use SSH "under the hood", like git. A pity I can't upvote it more.
    – rsuarez
    Commented Aug 7, 2019 at 15:10
  • 7
    +1 Set IdentityAgent to none if you need to set this in your config file.
    – user541686
    Commented May 21, 2020 at 12:42
  • @user541686 Nice, this works a lot better for me than -o IdentitiesOnly=yes -i … in many situations.
    – huyz
    Commented Apr 16, 2023 at 6:13

You had the answer all along (almost):

Host *
PreferredAuthentications keyboard-interactive,password

Worked for me.

  • 11
    The question asked about how to limit which public keys are used. This answer disables public key authentication entirely. Commented Jun 12, 2012 at 22:11

All answers to this question focus on enforcement options of SSH. Actually, there is a much simpler way: do not keep your keys in ~/.ssh folder. Just keep them elsewhere, e.g. in ~/.ssh/my_keys/. Then your SSH client won't bother trying any unexpected keys, just do not store your keys in a folder, where it expects the keys to try to be stored.

You must log in to answer this question.

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