How could I stop ssh offering a wrong key?

37,099

Solution 1

This is expected behaviour according to the manpage of ssh_config:

 IdentityFile
         Specifies a file from which the user's DSA, ECDSA or DSA authentica‐
         tion identity is read.  The default is ~/.ssh/identity for protocol
         version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for
         protocol version 2.  Additionally, any identities represented by the
         authentication agent will be used for authentication.  

         [...]

         It is possible to have multiple identity files specified in configu‐
         ration files; all these identities will be tried in sequence.  Mul‐
         tiple IdentityFile directives will add to the list of identities
         tried (this behaviour differs from that of other configuration
         directives).

Basically, specifying IdentityFiles just adds keys to a current list the SSH agent already presented to the client.

Try overriding this behaviour with this at the bottom of your .ssh/config file:

Host *
IdentitiesOnly yes

Solution 2

For me the solution was to add a key to a list of ssh keys, with a command:

ssh-add ~/.ssh/id_name_of_my_rsa_key

so it could be offered when connecting to the server. After adding a ssh, it was automatically recognized the correct one.

Edit:

But recently I think the better solution, and more permanent one, is to go to ~/.ssh/config and add IdentitiesOnly yes in your configuration file like this:

Host github.com
  HostName github.com
    User git
      IdentityFile ~/.ssh/id_rsa
      IdentitiesOnly yes
Share:
37,099

Related videos on Youtube

Alvaro Maceda
Author by

Alvaro Maceda

Updated on September 18, 2022

Comments

  • Alvaro Maceda
    Alvaro Maceda almost 2 years

    (This is a problem with ssh, not gitolite)

    I've configured gitolite on my home server (ubuntu 12.04 server, open-ssh). I want an special identityfile to administer the repositories, so I need to access throught ssh to my own host ussing two different identity keys.

    This is the content of my .ssh/config file:

    Host gitadmin.gammu.com
    User            git
    IdentityFile    /home/alvaro/.ssh/id_gitolite_mantra
    
    Host git.gammu.com
    User            git
    IdentityFile    /home/alvaro/.ssh/id_alvaro_mantra
    

    This is the content of my hosts file:

    # Git
    127.0.0.1      gitadmin.gammu.com
    127.0.0.1      git.gammu.com
    

    So I should be able to communicate with gitolite this way to access with the "normal" account:

    $ssh git.gammu.com 
    

    and this way to access with the administrative account:

    $ssh gitadmin.gammu.com
    

    When I try to access with the normal account, all is ok:

    alvaro@mantra:~/.ssh$ ssh git.gammu.com
    PTY allocation request failed on channel 0
    hello alvaro, this is gitolite 2.2-1 (Debian) running on git 1.7.9.5
    the gitolite config gives you the following access:
        @R_ @W_    testing
    Connection to git.gammu.com closed.
    

    When I do the same with the administrative account:

    alvaro@mantra:~$ ssh gitadmin.gammu.com
    PTY allocation request failed on channel 0
    hello alvaro, this is gitolite 2.2-1 (Debian) running on git 1.7.9.5
    the gitolite config gives you the following access:
        @R_ @W_    testing
    Connection to gitadmin.gammu.com closed.
    

    It should show the administrative repository. If I launch ssh with verbose option:

    ssh -vvv gitadmin.gammu.com 
    ...
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug2: service_accept: ssh-userauth
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug2: key: /home/alvaro/.ssh/id_alvaro_mantra (0x7f7cb6c0fbc0)
    debug2: key: /home/alvaro/.ssh/id_gitolite_mantra (0x7f7cb6c044d0)
    debug1: Authentications that can continue: publickey,password
    debug3: start over, passed a different list publickey,password
    debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
    debug3: authmethod_lookup publickey
    debug3: remaining preferred: keyboard-interactive,password
    debug3: authmethod_is_enabled publickey
    debug1: Next authentication method: publickey
    debug1: Offering RSA public key: /home/alvaro/.ssh/id_alvaro_mantra
    debug3: send_pubkey_test
    debug2: we sent a publickey packet, wait for reply
    debug1: Server accepts key: pkalg ssh-rsa blen 279
    ...
    

    It's offering the key id_alvaro_mantra, and it shouldn't!!

    The same happens when I specify the key with the -i option:

    ssh -i /home/alvaro/.ssh/id_gitolite_mantra -vvv gitadmin.gammu.com
    ...
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug2: service_accept: ssh-userauth
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug2: key: /home/alvaro/.ssh/id_alvaro_mantra (0x7fa365237f90)
    debug2: key: /home/alvaro/.ssh/id_gitolite_mantra (0x7fa365230550)
    debug2: key: /home/alvaro/.ssh/id_gitolite_mantra (0x7fa365231050)
    debug1: Authentications that can continue: publickey,password
    debug3: start over, passed a different list publickey,password
    debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
    debug3: authmethod_lookup publickey
    debug3: remaining preferred: keyboard-interactive,password
    debug3: authmethod_is_enabled publickey
    debug1: Next authentication method: publickey
    debug1: Offering RSA public key: /home/alvaro/.ssh/id_alvaro_mantra
    debug3: send_pubkey_test
    debug2: we sent a publickey packet, wait for reply
    debug1: Server accepts key: pkalg ssh-rsa blen 279
    debug2: input_userauth_pk_ok: fp 36:b1:43:36:af:4f:00:e5:e1:39:50:7e:07:80:14:26
    debug3: sign_and_send_pubkey: RSA 36:b1:43:36:af:4f:00:e5:e1:39:50:7e:07:80:14:26
    debug1: Authentication succeeded (publickey).
    ...
    

    What's happening? I'm missing something, but I can't find what.

    These are the contents of my home dir:

    -rw-rw-r--  1 alvaro alvaro  395 nov 14 18:00 authorized_keys
    -rw-rw-r--  1 alvaro alvaro  326 nov 21 10:21 config
    -rw-------  1 alvaro alvaro  137 nov 20 20:26 environment
    -rw-------  1 alvaro alvaro 1766 nov 20 21:41 id_alvaromaceda.es
    -rw-r--r--  1 alvaro alvaro  404 nov 20 21:41 id_alvaromaceda.es.pub
    -rw-------  1 alvaro alvaro 1766 nov 14 17:59 id_alvaro_mantra
    -rw-r--r--  1 alvaro alvaro  395 nov 14 17:59 id_alvaro_mantra.pub
    -rw-------  1 alvaro alvaro  771 nov 14 18:03 id_developer_mantra
    -rw-------  1 alvaro alvaro 1679 nov 20 12:37 id_dos_pruebasgit
    -rw-r--r--  1 alvaro alvaro  395 nov 20 12:37 id_dos_pruebasgit.pub
    -rw-------  1 alvaro alvaro 1679 nov 20 12:46 id_gitolite_mantra
    -rw-r--r--  1 alvaro alvaro  397 nov 20 12:46 id_gitolite_mantra.pub
    -rw-------  1 alvaro alvaro 1675 nov 20 21:44 id_gitpruebas.es
    -rw-r--r--  1 alvaro alvaro  408 nov 20 21:44 id_gitpruebas.es.pub
    -rw-------  1 alvaro alvaro 1679 nov 20 12:34 id_uno_pruebasgit
    -rw-r--r--  1 alvaro alvaro  395 nov 20 12:34 id_uno_pruebasgit.pub
    -rw-r--r--  1 alvaro alvaro 2434 nov 21 10:11 known_hosts
    

    There are a bunch of other keys which aren't offered... why id_alvaro_mantra is offered and not the other keys? I can't understand.

    I need some help, don't know where to look....

  • Alvaro Maceda
    Alvaro Maceda over 11 years
    Thanks a lot, that worked. I'd completly forgotten ssh-agent!
  • Alvaro Maceda
    Alvaro Maceda over 11 years
    Also, you can specify it on the host level, that's what I've done finally: Host git.gammu.com User git IdentityFile /home/alvaro/.ssh/id_alvaro_mantra IdentitiesOnly yes`
  • Bruno Bronosky
    Bruno Bronosky almost 10 years
    @AlvaroMaceda is correct. Adding IdentitiesOnly yes to the gitadmin.gammu.com and git.gammu.com Host entries is enough. You don't have to make a wildcard entry that will affect other hosts.
  • dess
    dess over 4 years
    Thank you, your second approach was exactly what I should do. Side notes: HostName is excessive in your example since its value equals Host's, indentation more than one level has no means since there's grouping by Host and Match in ssh_config only.
  • Daryl
    Daryl over 4 years
    The second approach was the only one that worked for me on OS X Catalina.
  • Admin
    Admin almost 2 years
    Finally I found the solution, thanks! This should be enabled by default.