How to Override SSH Default Identity

ssh

Short version: how can I disable/override the default SSH identity file locations ~/.ssh/id_{rsa,dsa} and force SSH to use another one (first)?

Long version:

I'm trying to setup gitolite with ssh key access. From my client I'd like to access the gitolite-admin repository with my default ~/.ssh/id_rsa identity, while I've created a separate identity ~/.ssh/id_rsa_git to access the normal repositories.

Furthermore, I created an SSH alias in ~/.ssh/config:

Host git
    Hostname <servername>
    User gitolite
    ForwardX11 no
    ForwardAgent no
    GSSAPIAuthentication no
    IdentityFile ~/.ssh/id_rsa_git

Now when I try to access the gitolite repository as non-admin user, I get

$ ssh -v git true
OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /home/jaap/.ssh/config
debug1: /home/jaap/.ssh/config line 105: Applying options for git
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to <servername> port 22.
debug1: Connection established.
debug1: identity file /home/jaap/.ssh/id_rsa_git type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/jaap/.ssh/id_rsa_git-cert type -1
debug1: identity file /home/jaap/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-1024
debug1: identity file /home/jaap/.ssh/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze3
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze3 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4
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 <...>
debug1: Host '<servername>' is known and matches the RSA host key.
debug1: Found key in /home/jaap/.ssh/known_hosts:19
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_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/jaap/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: Authentication succeeded (publickey).

This shows that my default key ./ssh/id_rsa is offered first and gets accepted. But this key does not provide access to the non-admin repositories, so I want SSH to offer only/first ./ssh/id_rsa_git. How can I do this?

I've tried adding IdentitiesOnly=yes, but that only disables ssh-agent keys. It seems there is no option in ssh configuration (site-wide or per-user) to disable the default identities, but I also cannot find a way to specify their order.

Best Answer

There is an SSH Config setting called IdentitiesOnly that defaults to "no". Set it to yes in your config file (globally or for a specific host) and your problem should be solved.

e.g., put this in ~/.ssh/config:

Host your.server.com
    IdentityFile ~/example/your_new.key
    User your_user
    IdentitiesOnly yes

From the Man page for ssh_config:

 IdentitiesOnly
         Specifies that ssh(1) should only use the authentication identity
         files configured in the ssh_config files, even if ssh-agent(1) or a
         PKCS11Provider 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''.

I was having the exact same problem (and getting locked out by fail2ban). This fixed it.

Related Question