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

Question

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

У меня есть сервер 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 

При попытке подключиться к мерзавца машины:

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 
git@git.mygitlab.com's password: 

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

Я просто столкнулся с этой проблемой, когда я переключился на сервер 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, и все нормально работало.

Answer 4

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