SSH-ключи GitLab перестали работать

Хорошо, я много раз натыкался на эту тему, но это первый раз, когда ни одно из обычных решений не сработало.

У меня есть сервер CentOS 6.4, на котором работает GitLab. Он отлично работал с 20+ пользователями и 60+ проектами, но около 5 часов назад мой основной промежуточный сервер не смог впервые подключиться к машине GitLab с помощью аутентификации по ключу и запросил пароль. Я повторно сгенерировал ключ RSA и добавил его в свои ключи развертывания, но это также не удалось.

Затем я попытался создать нового пользователя на промежуточном сервере, создать для него ключ и добавить его в GitLab, но все равно не получается.

Разрешения:

drwxr-x---  22 root root 4.0K Oct 28 13:20 root

Внутренний корень:

drwx------   2 root root     4096 Oct 28 11:49 .ssh

Внутри .ssh:

-rw-------  1 root root  227 Oct 28 11:48 authorized_keys
-rw-------  1 root root 1675 Oct 28 13:09 id_rsa
-rw-------  1 root root  398 Oct 28 13:09 id_rsa.pub
-rw-r--r--  1 root root  413 Oct 28 11:49 known_hosts

Когда я пытаюсь подключиться к машине git:

OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to git.mygitlab.com [212.29.122.24] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'git.mygitlab.com' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-    mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-    mic,password
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
[email protected]'s password:

Когда я добавляю ключи SSH через веб-интерфейс, они не добавляются в .ssh/authorized_keys.

Я действительно не знаю, что попробовать дальше :(


person SlipY    schedule 28.10.2013    source источник
comment
Вы видите свой открытый ключ в git.mygitlab.com:~git/.ssh/authorized_keys?   -  person VonC    schedule 28.10.2013
comment
вообще-то, нет ! у меня есть 49 ключей в файлах авторизованных ключей на сервере gitlab, когда я добавляю дополнительные ключи, они не появятся   -  person SlipY    schedule 28.10.2013
comment
Так что проблема именно в этом. Есть ли какой-нибудь журнал в gitlab, который оставил бы подсказку?   -  person VonC    schedule 28.10.2013
comment
ничего из того, что я могу найти, я могу добавить ключи ssh в веб-интерфейс gitlab, но они не добавятся в author_keys   -  person SlipY    schedule 28.10.2013
comment
Значит, простая перезагрузка не поможет? (как в github.com/gitlabhq/gitlabhq/issues/4733)   -  person VonC    schedule 28.10.2013
comment
к сожалению, я перезапустил обе машины.. не помогло.   -  person SlipY    schedule 28.10.2013
comment
Я полагаю, страница устранения неполадок тоже не помогает?   -  person VonC    schedule 28.10.2013
comment
И это не проблема chown или chgrp, как в github.com/gitlabhq/gitlabhq/issues. /1345?   -  person VonC    schedule 28.10.2013
comment
ничто из вышеперечисленного не связано с синхронизацией Gitlab с авторизованными файлами ключей. так как я использую старую версию (4.0), я пытаюсь обновить версию за версией, чтобы увидеть, решена ли она   -  person SlipY    schedule 28.10.2013
comment
Я не знал о версии GitLab. Я подтверждаю, что обновление до 6.x, безусловно, будет чем-то, что можно будет протестировать, и оно может решить всю проблему.   -  person VonC    schedule 28.10.2013


Ответы (4)


Если ключи, которые вы добавляете в GitLab, не попадают в .ssh/authorized_keys:

  1. Убедитесь, что программа sidekiq запущена. Ключи добавляются в gitlab-shell в воркере Sidekiq, поэтому, если Sidekiq не работает или задерживается, они не войдут. Вы можете проверить это в выводе ps -fu git и проверив вкладку «фоновые задания» на странице администратора. .
  2. Убедитесь, что GitLab может правильно выполнять gitlab-shell. Рабочий процесс Sidekiq добавляет ключи с помощью выполнение процесса gitlab-shell. В частности, это не сработает, если параметр ssh_user неверен в gitlab.yml. или если gitlab-shell установлен не в ~/gitlab-shell месте для этого пользователя.
  3. Убедитесь, что раздел /home сервера не заполнен. Если диск, на котором хранится файл authorized_keys, заполнен, ключ добавляется с ошибкой! Этот мне попадался несколько раз. Используйте df -h /home, чтобы узнать, есть ли у вас еще место.

Проверьте свои журналы на наличие сообщений об ошибках от gitlab-shell: в зависимости от проблемы сообщения об ошибках могут появиться в журналах unicorn или sidekiq.

person Ash Wilson    schedule 28.10.2013
comment
Привет, Эш, ты прав на 100%, но, как я уже сказал, я использую старую версию Gitlab (4.1), и у меня нет gitlab-shell.. я пытаюсь обновить версию за версией, пока она не будет обновлена - person SlipY; 28.10.2013
comment
О, точно, я пропустил этот момент. Да, 4.1 был еще во времена гитолита. Если вы вытащите репозиторий конфигурации gitolite напрямую, ваши ключи попадут в настройки gitolite? Если нет, то есть задача Rake для ресинхронизации всего: rake gitlab:gitolite:update_keys - person Ash Wilson; 28.10.2013
comment
Также возможно, что с вашей установкой gitolite что-то не так, например, отсутствующий или неисполняемый хук post-receive. Дважды проверьте установку gitolite: github.com/sitaramc/gitolite - person Ash Wilson; 28.10.2013

Ну, теперь я под 5.1, я сделал это шаг за шагом 4.1> 4,2 4,2> 4,3 и, наконец, все работает.

Просто для сведения пользователей версии 4.1 -> один из разработчиков добавил неверный ключ, включая $#root... и это нарушило синхронизацию.

Спасибо за помощь

person SlipY    schedule 30.10.2013
comment
Интересно знать. +1 - person VonC; 30.10.2013

Я просто столкнулся с этой проблемой, когда переключил сервер GitLab с HTTP на HTTPS. На веб-сервере все выглядело нормально - входы в систему и т. Д. Все работали нормально, но соединения git @ gitlab SSH терпели неудачу.

Посмотрев на # 2 в https://stackoverflow.com/a/19637026/2162639 (выше), я обнаружил, что я необходимо изменить настройку gitlab_url в /home/git/gitlab-shell/config.yaml, чтобы использовать https://gitlab.server.fqdn вместо http://gitlab.server.fqdn. Я изменил этот параметр, перезапустил службу gitlab, и все заработало нормально.

person Greg Lund-Chaix    schedule 27.02.2014

Пришлось удалить все предыдущие ключи для хоста. Проблема в том, что gitlab принимает любые старые ключи, и если совпадение не существует, там происходит сбой. Ваш рабочий ключ может быть указан позже по порядку и так и не выбран.

person Joviano Dias    schedule 23.04.2014