Як я можу зупинити ssh, пропонуючи неправильний ключ?


33

(Це проблема з ssh, а не з гітолітом)

Я налаштував гітоліт на своєму домашньому сервері (сервер ubuntu 12.04, open-ssh). Я хочу, щоб спеціальний файл ідентифікації був призначений для адміністрування сховищ, тому мені потрібно отримати доступ до 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 пропонується, а не інші ключі? Я не можу зрозуміти.

Мені потрібна допомога, не знаю, де шукати ....

Відповіді:


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-агент!
Альваро Маседа

3
Крім того, ви можете вказати це на рівні хоста, ось що я зробив нарешті: Host git.gammu.com User git IdentityFile /home/alvaro/.ssh/id_alvaro_mantra IdentitiesOnly yes`
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/configта додати IdentitiesOnly yesйого так:

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

Дякую, ваш другий підхід був саме тим, що я повинен зробити. Бічні зауваження: HostName у вашому прикладі надмірний, оскільки його значення дорівнює хосту, відступ більше одного рівня не має засобів, оскільки існує групування за хостом і збігом лише в ssh_config.
деск

Другий підхід був єдиним, який працював для мене на OS X Catalina.
Дарил
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.