Назад | Перейти на главную страницу

После восстановления резервной копии GitLab новые открытые ключи SSH случайным образом заменяют существующие ключи других пользователей.

Это произошло при новой (не обновленной) установке GitLab 8.6.4.

Я установил GitLab, и моя команда его оценила. Конечно, я и другие ввели наши открытые ключи SSH.

В рамках нашей оценки я сделал резервную копию GitLab и восстановил ее.

После того, как я восстановил резервную копию, новый пользователь Шунг Ван ввел свой открытый ключ SSH.

Теперь, когда я пытаюсь получить доступ к репозиториям git через SSH, сервер думает, что я Шунг Ван. Например, когда я тестировал свое SSH-соединение со своего ноутбука Ubuntu 14.04, я получил следующее:

ssh -T git@gitserver Welcome to GitLab, Shung Wang!

В качестве второго теста я попытался клонировать частный репозиторий, к которому у Шунга не было доступа:

git clone git@gitserver:sw/devops.git Cloning into 'devops'... GitLab: The project you were looking for could not be found. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.

Затем я сделал Шунга участником проекта DevOps, и git clone удалось. Я действительно обращаюсь к репозиториям GitLab как Shung Wang.

Очевидно, это крайне неудовлетворительная ситуация с безопасностью. Как я могу получить доступ к репозиториям GitLab как я, кроме Шунг Ванга?

Объяснение

GitLab поддерживает файл ~git/.ssh/authorized_keys, в котором каждому открытому ключу SSH присваиваются имена. key-1, key-2, и так далее.

После восстановления из резервной копии имя сбрасывается на key-1, поэтому последующие ключи имеют повторяющиеся имена. Вот мой ~git/.ssh/authorized_keys файл, показывающий мой ключ и ключ Шунг Ванга, оба названы key-1:

# Managed by gitlab-shell
command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAA...2SkSQ== jm...@wavecomp.com
###################################################################################################################################################################################
#####################################################################################################################################################################################
command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAA...nKQ== wang....@wavecomp.com
...

По-видимому, последнее появление key-1 используется и для меня, и для Шунга.

Я сообщил об этой ошибке GitLab в GitLab, выпуск 1263.

Обходные пути

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

Обходной путь 1

Использовать sudo gitlab-rake gitlab:shell:setup к восстановить authorized_keys файл

Обходной путь 2

Я рекомендую сначала попробовать обходной путь 1.

Ниже приводится то, что я на самом деле делал сам, прежде чем обнаружил обходной путь 1.

  1. После восстановления резервной копии войдите в систему как существующий пользователь и зарегистрируйте новый открытый ключ SSH.
  2. Искать в файле ~git/.ssh/authorized_keys для key-1. Если вы найдете два, у вас проблема, описанная выше.
  3. Эти строки ######... не украшение. Это ключи, которые были удалены пользователями. Когда ключ удаляется, GitLab заменяет каждый его символ на #, предположительно, чтобы оставшиеся ключи не перемещались в файле. Замените все символы во всех ключах SSH, созданных до восстановления из резервной копии, на # персонаж в стиле, похожем на то, что вы видите в ~git/.ssh/authorized_keys показано выше.
  4. Скажите всем своим пользователям, что они должны повторно ввести свои открытые ключи SSH. Если они жалуются, напомните им, чтобы они были благодарны за то, что остальная часть резервной копии сработала.

Я подозреваю, что вместо утомительного редактирования на шаге 3 вы можете просто переместить файл ~git/.ssh/authorized_keys в сторону и замените его пустым файлом, а затем попросите всех повторно ввести свои открытые ключи SSH. Однако сам я этого не пробовал. Если это сработает для вас, сообщите нам в комментарии.