После восстановления резервной копии GitLab новые открытые ключи SSH случайным образом заменяют существующие ключи других пользователей
Это произошло с новой (не обновленной) установкой GitLab 8.6.4.
Я установил GitLab, и моя команда провела его оценку. Конечно, я и другие ввели наши открытые ключи SSH.
В рамках нашей оценки я сделал резервную копию GitLab и восстановил ее.
После того, как я восстановил резервную копию, новый пользователь Шунг Ван ввел свой открытый ключ SSH.
Теперь, когда я пытаюсь получить доступ к репозиториям git через SSH, сервер думает, что я Шунг Ван. Например, когда я тестировал свое SSH-соединение со своего ноутбука Ubuntu 14.04, я получил следующее:
ssh -T
Я установил GitLab, и моя команда провела его оценку. Конечно, я и другие ввели наши открытые ключи SSH.
В рамках нашей оценки я сделал резервную копию GitLab и восстановил ее.
После того, как я восстановил резервную копию, новый пользователь Шунг Ван ввел свой открытый ключ SSH.
Теперь, когда я пытаюсь получить доступ к репозиториям git через SSH, сервер думает, что я Шунг Ван. Например, когда я тестировал свое SSH-соединение со своего ноутбука Ubuntu 14.04, я получил следующее:
ssh -T
Я установил GitLab, и моя команда провела его оценку. Конечно, я и другие ввели наши открытые ключи SSH.
В рамках нашей оценки я сделал резервную копию GitLab и восстановил ее.
После того, как я восстановил резервную копию, новый пользователь Шунг Ван ввел свой открытый ключ SSH.
Теперь, когда я пытаюсь получить доступ к репозиториям git через SSH, сервер думает, что я Шунг Ван. Например, когда я тестировал свое SSH-соединение со своего ноутбука Ubuntu 14.04, я получил следующее:
ssh -Tgit @ gitserver
Добро пожаловать в GitLab, Шунг Ван!
В качестве второго теста я попытался клонировать частный репозиторий, к которому у Шунга не было доступа:
git clone git @ gitserver : sw / DevOps.git
Клонирование в DevOps ...
GitLab: Не удалось найти искомый проект.
фатальный: не удалось прочитать из удаленного репозитория.
Убедитесь, что у вас есть правильные права доступа
и репозиторий существует.
Затем я сделал Шунга участником проекта DevOps, и git clone преуспел. Я действительно обращаюсь к репозиториям GitLab как Шунг Ван.
Очевидно, это крайне неудовлетворительная ситуация с безопасностью. Как я могу получить доступ к репозиториям GitLab как я, кроме Шунга Ванга?
Explanation
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:shell:setup для восстановления файла authorized_keys file
Workaround 2
Я рекомендую сначала попробовать обходной путь 1.
Ниже перечислено, что я на самом деле делал сам до обнаружения обходного пути 1.
- После восстановления резервной копии войдите в систему как какой-нибудь существующий пользователь и зарегистрируйте новый открытый ключ SSH
- Файл поиска
~git/.ssh/authorized_keysдля ключаkey-1. Если вы найдете две, то у вас возникнет проблема, описанная выше. - Эти строки
######...не являются декорациями. Это ключи, которые были удалены пользователями. Когда ключ удаляется, GitLab заменяет каждый символ в нём на#, предположительно так, чтобы остальные ключи не перемещались в файле. Замените все символы во всех SSH-ключах, созданных до восстановления резервной копии, на символ#, как показано выше в~git/.ssh/authorized_keys. - Скажите всем своим пользователям, что они должны повторно ввести свои SSH-доступные ключи. Если они пожалуются, напомните им, чтобы они были благодарны за то, что остальная часть резервной копии сработала.
Вместо всего этого утомительного редактирования на шаге 3, я подозреваю, что вы можете просто переместить файл ~git/.ssh/authorized_keys в сторону и заменить его пустым файлом, а затем сказать всем, чтобы они снова ввели свои SSH-доступные ключи. Однако я сам этого не пробовал. Если это сработает, пожалуйста, скажите нам в комментарии