У меня есть сервер Ubuntu 12.04 в моей офисной сети, который используется для размещения наших репозиториев git. Сервер работает под управлением Gitlab 7.1.1 и имеет SSH на нестандартном порту.
Он отлично работает для всех внутри и за пределами офисной сети, за одним исключением. Исключением является управляемый сервер хостинговой компании, поэтому у меня ограниченный доступ к нему.
Когда я пытаюсь клонировать репо на нестандартный порт, время ожидания истекает. Я предполагаю, что это связано с тем, что исходящий порт заблокирован хостинговой компанией. Чтобы решить эту проблему, я настраиваю переадресацию портов на своем офисном маршрутизаторе для перенаправления входящего трафика через порт 22 на мой нестандартный порт на сервере git. Я тестировал путем клонирования с Digial Ocean VPS без указания порта, и он работал нормально.
Но проблемный сервер теперь выдает следующую ошибку:
Access denied.
fatal: The remote end hung up unexpectedly
Сервер git регистрирует создаваемое SSH-соединение и принимает открытый ключ, как показано на /var/log/auth.log:
Jan 20 15:09:07 gitlab sshd[3043]: Accepted publickey for git from 10.0.1.254 port 60771 ssh2
Jan 20 15:09:07 gitlab sshd[3043]: pam_unix(sshd:session): session opened for user git by (uid=0)
Jan 20 15:09:09 gitlab sshd[3162]: Received disconnect from 10.0.1.254: 11: disconnected by user
Jan 20 15:09:09 gitlab sshd[3043]: pam_unix(sshd:session): session closed for user git
Это не отличается от любого другого запроса авторизации в журнале, поэтому я понятия не имею, почему клон не работает?
Я устанавливаю тестовое репо на Github, и проблемные серверные клоны отлично работают по SSH. По какой-то причине у него просто проблема с репозиториями с моего офисного сервера через SSH.
Также стоит отметить, что проблемный сервер может клонировать через HTTP с именем пользователя и паролем в порядке, проблема только через SSH.
Есть идеи, в чем проблема?
PS, я больше программист, чем администратор сервера, я участвую в этом, чтобы попытаться улучшить процесс развертывания в моей компании, так что многое из этого для меня в новинку
Я решил это.
Проблема заключалась в том, что открытый ключ проблемного сервера уже был добавлен в Gitlab в качестве «ключа развертывания» для более раннего несвязанного тестирования. Затем он был удален как ключ развертывания, но по какой-то причине ключ сохранился в БД Gitlab. Затем Gitlab позволил мне повторно добавить тот же ключ для тестового пользователя, не жалуясь, что он уже существует в другом месте в БД. Но при попытке аутентификации с этим ключом Gitlab будет искать ключ и получать первый «потерянный» ключ, поэтому он будет предоставлять только анонимный доступ, который, очевидно, не позволит клонировать.
Чтобы решить эту проблему, я нашел идентификатор потерянного ключа и удалил его с помощью git-shell:
./bin/gitlab-keys rm-key key-21
куда 21 был идентификатором потерянного ключа.
Теперь все работает как положено.