如何停止ssh提供错误的密钥?


33

(这是ssh的问题,不是gitolite的问题)

我在家庭服务器(ubuntu 12.04服务器,open-ssh)上配置了gitolite。我想要一个特殊的Identityfile来管理存储库,因此我需要使用两个不同的身份密钥通过ssh访问我自己的主机。

这是我的.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

这是我的主机文件的内容:

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

因此,我应该能够通过这种方式与gitolite进行通信,以使用“普通”帐户进行访问:

$ssh git.gammu.com 

以及使用管理帐户进行访问的方式:

$ssh gitadmin.gammu.com

当我尝试使用普通帐户访问时,一切正常:

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.

当我对管理帐户执行相同操作时:

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.

它应该显示管理存储库。如果我使用详细选项启动ssh:

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

它提供了密钥id_alvaro_mantra,它不应该!

当我使用-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).
...

发生了什么?我想念什么,但找不到。

这些是我的主目录的内容:

-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

还有很多其他键没有提供...为什么提供id_alvaro_mantra而不提供其他键?我听不懂

我需要一些帮助,不知道在哪里寻找...。

Answers:


53

根据以下手册,这是预期的行为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).

基本上,指定IdentityFiles只是将密钥添加到已经提供给客户端的SSH代理的当前列表中。

请尝试在.ssh/config文件底部使用此方法来覆盖此行为:

Host *
IdentitiesOnly yes

非常感谢,这行得通。我会完全忘记ssh-agent!
Alvaro Maceda '11年

3
另外,您可以在主机级别指定它,这就是我最终要做的事情:Host git.gammu.com User git IdentityFile /home/alvaro/.ssh/id_alvaro_mantra IdentitiesOnly是`
Alvaro Maceda

2
@AlvaroMaceda是正确的。将条目添加IdentitiesOnly yes到gitadmin.gammu.com和git.gammu.com中Host就足够了。您不必输入会影响其他主机的通配符条目。
布鲁诺·布罗诺斯基

6

对我来说,解决方案是使用命令将密钥添加到ssh密钥列表中:

ssh-add ~/.ssh/id_name_of_my_rsa_key

因此可以在连接服务器时提供。添加ssh后,系统会自动识别出正确的ssh。

编辑:

但是最近,我认为更好的解决方案(也是更永久的解决方案)是转到~/.ssh/config并添加IdentitiesOnly yes您的配置文件,如下所示:

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

谢谢,您的第二种方法正是我应该做的。旁注:由于您的示例中的HostName值等于Host的值,因此HostName是过多的,缩进不止一个级别,因为仅在ssh_config中按Host和Match进行分组。
des

第二种方法是在OS X Catalina上对我有用的唯一方法。
达里尔
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.