Come potrei impedire a ssh di offrire una chiave sbagliata?

33

(Questo è un problema con ssh, non con gitolite)

Ho configurato gitolite sul mio server di casa (server Ubuntu 12.04, open-ssh). Voglio un file di identità speciale per amministrare i repository, quindi devo accedere attraverso ssh al mio host usando due diverse chiavi di identità.

Questo è il contenuto del mio file .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

Questo è il contenuto del mio file hosts:

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

Quindi dovrei essere in grado di comunicare con gitolite in questo modo per accedere con l'account "normale":

$ssh git.gammu.com

e in questo modo per accedere con l'account amministrativo:

$ssh gitadmin.gammu.com

Quando provo ad accedere con l'account normale, va tutto bene:

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.

Quando faccio lo stesso con l'account amministrativo:

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.

Dovrebbe mostrare il repository amministrativo. Se lancio ssh con l'opzione dettagliata:

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

Offre la chiave id_alvaro_mantra e non dovrebbe !!

Lo stesso succede quando specifico la chiave con l'opzione -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).
...

Cosa sta succedendo? Mi manca qualcosa, ma non riesco a trovare cosa.

Questi sono i contenuti della mia home directory:

-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

Ci sono un sacco di altre chiavi che non sono offerte ... perché id_alvaro_mantra è offerto e non le altre chiavi? Non capisco

Ho bisogno di aiuto, non so dove cercare ...

ssh  gitolite  identity-management 
— Alvaro Maceda
fonte

Risposte:

53

Questo è un comportamento previsto secondo la manpage di 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).

Fondamentalmente, specificando IdentityFiles si aggiungono semplicemente le chiavi a un elenco corrente che l'agente SSH ha già presentato al client.

Prova a ignorare questo comportamento con questo nella parte inferiore del tuo .ssh/configfile:

Host *
IdentitiesOnly yes
— gertvdijk
fonte
Grazie mille, ha funzionato. Avevo completamente dimenticato l'agente ssh!
— Alvaro Maceda,
3
Inoltre, puoi specificarlo a livello di host, ecco cosa ho fatto finalmente: Host git.gammu.com User git IdentityFile /home/alvaro/.ssh/id_alvaro_mantra IdentitiesSolo sì`
— Alvaro Maceda,
2
@AlvaroMaceda è corretto. L'aggiunta IdentitiesOnly yesalle Hostvoci gitadmin.gammu.com e git.gammu.com è sufficiente. Non è necessario inserire una voce jolly che influirà su altri host.
— Bruno Bronosky,
6

Per me la soluzione era aggiungere una chiave a un elenco di chiavi ssh, con un comando:

ssh-add ~/.ssh/id_name_of_my_rsa_key

quindi potrebbe essere offerto durante la connessione al server. Dopo aver aggiunto un ssh, è stato riconosciuto automaticamente quello corretto.

Modificare:

Ma recentemente penso che la soluzione migliore, e più permanente, sia quella di andare ~/.ssh/confige aggiungere il IdentitiesOnly yestuo file di configurazione in questo modo:

Host github.com
  HostName github.com
    User git
      IdentityFile ~/.ssh/id_rsa
      IdentitiesOnly yes
— Aleks
fonte
Grazie, il tuo secondo approccio era esattamente quello che avrei dovuto fare. Note a margine: HostName è eccessivo nel tuo esempio poiché il suo valore è uguale a quello di Host, il rientro di più di un livello non ha alcun mezzo poiché c'è raggruppamento per Host e Match solo in ssh_config.
— Dess
Il secondo approccio è stato l'unico che ha funzionato per me su OS X Catalina.
— Daryl
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.