Это произошло при новой (не обновленной) установке 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.
Пока ошибка не будет исправлена, пользователи могут попробовать эти обходные пути.
Использовать sudo gitlab-rake gitlab:shell:setup
к восстановить authorized_keys
файл
Я рекомендую сначала попробовать обходной путь 1.
Ниже приводится то, что я на самом деле делал сам, прежде чем обнаружил обходной путь 1.
~git/.ssh/authorized_keys
для key-1
. Если вы найдете два, у вас проблема, описанная выше.######...
не украшение. Это ключи, которые были удалены пользователями. Когда ключ удаляется, GitLab заменяет каждый его символ на #
, предположительно, чтобы оставшиеся ключи не перемещались в файле. Замените все символы во всех ключах SSH, созданных до восстановления из резервной копии, на #
персонаж в стиле, похожем на то, что вы видите в ~git/.ssh/authorized_keys
показано выше.Я подозреваю, что вместо утомительного редактирования на шаге 3 вы можете просто переместить файл ~git/.ssh/authorized_keys
в сторону и замените его пустым файлом, а затем попросите всех повторно ввести свои открытые ключи SSH. Однако сам я этого не пробовал. Если это сработает для вас, сообщите нам в комментарии.