Frage Wie könnte ich aufhören, einen falschen Schlüssel anzubieten?


(Dies ist ein Problem mit SSH, nicht Gitolit)

Ich habe gitolite auf meinem Heimserver (ubuntu 12.04 Server, open-ssh) konfiguriert. Ich möchte eine spezielle Identityfile, um die Repositories zu verwalten, also muss ich auf ssh zu meinem eigenen Host zugreifen using zwei verschiedene Identitätsschlüssel.

Dies ist der Inhalt meiner .ssh / config-Datei:

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

Dies ist der Inhalt meiner Hosts-Datei:

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

Also sollte ich in der Lage sein, mit Gitolite auf diese Weise mit dem "normalen" Konto zu kommunizieren:

$ssh git.gammu.com 

und auf diese Weise mit dem Administratorkonto zugreifen:

$ssh gitadmin.gammu.com

Wenn ich versuche, mit dem normalen Konto zuzugreifen, ist alles in Ordnung:

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.

Wenn ich das gleiche mit dem Administratorkonto mache:

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.

Es sollte das Administrations-Repository anzeigen. Wenn ich ssh mit der ausführlichen Option starte:

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

Es bietet den Schlüssel id_alvaro_mantra, und es sollte nicht !!

Das Gleiche passiert, wenn ich den Schlüssel mit der Option -i spezifiziere:

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

Was ist los? Ich vermisse etwas, aber ich kann nichts finden.

Dies sind die Inhalte meines 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

Es gibt eine Menge anderer Schlüssel, die nicht angeboten werden ... warum wird id_alvaro_mantra angeboten und nicht die anderen Schlüssel? Ich kann es nicht verstehen.

Ich brauche Hilfe, weiß nicht, wo ich suchen soll ....


29
2017-11-21 10:29


Ursprung




Antworten:


Dies ist das erwartete Verhalten gemäß der Manpage von 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).

Grundsätzlich spezifizieren IdentityFiles fügt nur Schlüssel zu einer aktuellen Liste hinzu, die der SSH-Agent dem Client bereits präsentiert hat.

Versuchen Sie, dieses Verhalten im unteren Bereich Ihres Browsers zu überschreiben .ssh/config Datei:

Host *
IdentitiesOnly yes

51
2017-11-21 11:18



Vielen Dank, das hat funktioniert. Ich hätte ssh-agent komplett vergessen! - Alvaro Maceda
Sie können es auch auf der Host-Ebene angeben, das habe ich schließlich getan: Host git.gammu.com  User git         IdentityFile /home/alvaro/.ssh/id_alvaro_mantra IdentitiesOnly ja` - Alvaro Maceda
@ AlvaroMaceda ist richtig. Hinzufügen IdentitiesOnly yes zum gitadmin.gammu.com und git.gammu.com Host Einträge sind genug. Sie müssen keinen Platzhaltereintrag erstellen, der sich auf andere Hosts auswirkt. - Bruno Bronosky


Für mich bestand die Lösung darin, einen Schlüssel zu einer Liste von SSH-Schlüsseln mit einem Befehl hinzuzufügen:

ssh-add ~/.ssh/id_name_of_my_rsa_key

So könnte es beim Verbinden mit dem Server angeboten werden. Nach dem Hinzufügen eines SSH wurde automatisch der richtige erkannt.

Bearbeiten:

Aber in letzter Zeit denke ich, dass die bessere und dauerhaftere Lösung darin besteht, zu gehen ~/.ssh/config und hinzufügen IdentitiesOnly yes in Ihrer Konfigurationsdatei so:

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

3
2018-01-12 13:09