Comment pourrais-je empêcher ssh d'offrir une mauvaise clé?

33

(C'est un problème avec ssh, pas avec de la gitolite)

J'ai configuré gitolite sur mon serveur domestique (serveur ubuntu 12.04, open-ssh). Je veux un fichier d'identité spécial pour administrer les référentiels, j'ai donc besoin d'accéder à travers ssh à mon propre hôte en utilisant deux clés d'identité différentes.

Voici le contenu de mon fichier .ssh / config:

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

Voici le contenu de mon fichier d'hôtes:

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

Je devrais donc pouvoir communiquer avec gitolite de cette façon pour accéder avec le compte "normal":

$ssh git.gammu.com

et de cette façon d'accéder avec le compte administratif:

$ssh gitadmin.gammu.com

Lorsque j'essaie d'accéder avec le compte normal, tout va bien:

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.

Quand je fais de même avec le compte administratif:

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.

Il doit afficher le référentiel administratif. Si je lance ssh avec l'option verbose:

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
...

Il offre la clé id_alvaro_mantra, et cela ne devrait pas !!

La même chose se produit lorsque je spécifie la clé avec l'option -i:

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).
...

Que ce passe-t-il? Il me manque quelque chose, mais je ne trouve pas quoi.

Voici le contenu de mon répertoire personnel:

-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

Il y a un tas d'autres clés qui ne sont pas offertes ... pourquoi id_alvaro_mantra est offert et pas les autres clés? Je ne comprends pas.

J'ai besoin d'aide, je ne sais pas où chercher ...

ssh gitolite identity-management Alvaro Maceda
la source

53

Il s'agit d'un comportement attendu selon la page de manuel de 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).

Fondamentalement, la spécification de IdentityFiles ajoute simplement des clés à une liste actuelle de l'agent SSH déjà présenté au client.

Essayez de remplacer ce comportement avec ceci au bas de votre .ssh/configfichier:

Host *
IdentitiesOnly yes

Gertvdijk
la source

Merci beaucoup, cela a fonctionné. J'avais complètement oublié ssh-agent!

Alvaro Maceda

3

En outre, vous pouvez le spécifier au niveau de l'hôte, c'est ce que j'ai finalement fait: Host git.gammu.com User git IdentityFile /home/alvaro/.ssh/id_alvaro_mantra IdentitiesOnly yes`

Alvaro Maceda

2

@AlvaroMaceda est correct. Ajouter IdentitiesOnly yesaux Hostentrées gitadmin.gammu.com et git.gammu.com est suffisant. Vous n'avez pas besoin de créer une entrée générique qui affectera les autres hôtes.

Bruno Bronosky

6

Pour moi, la solution était d'ajouter une clé à une liste de clés ssh, avec une commande:

ssh-add ~/.ssh/id_name_of_my_rsa_key

il pourrait donc être proposé lors de la connexion au serveur. Après avoir ajouté un ssh, il a été automatiquement reconnu le bon.

Modifier:

Mais récemment, je pense que la meilleure solution, et la plus permanente, est d'aller dans votre fichier de configuration ~/.ssh/configet de l'ajouter IdentitiesOnly yescomme ceci:

Host github.com
  HostName github.com
    User git
      IdentityFile ~/.ssh/id_rsa
      IdentitiesOnly yes

Aleks
la source

Merci, votre deuxième approche était exactement ce que je devais faire. Notes annexes: HostName est excessif dans votre exemple car sa valeur est égale à Host, l'indentation de plus d'un niveau n'a aucun moyen car il n'y a de regroupement par Host et Match que dans ssh_config.

dess

La deuxième approche était la seule qui fonctionnait pour moi sur OS X Catalina.

Daryl

Comment pourrais-je empêcher ssh d'offrir une mauvaise clé?

Réponses: