GitLab 5.0: Git push через SSH не работает, но нет ошибок с HTTPS или с прямым подключением SSH

Когда я пытаюсь выполнить git push, я получаю обычную ошибку

фатальный: Не удалось прочитать из удаленного репозитория.

Пожалуйста, убедитесь, что у вас есть правильные права доступа и репозиторий существует.

Тем не менее, push и pull отлично работают через HTTPS.

Я подумал, что тогда это будет проблема с SSH, но подключение, похоже, не вызывает никаких ошибок, оно принимает мой открытый ключ, выдает мне приветственное сообщение и завершает работу с 0.

$ ssh -vT [email protected]
OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/adam/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to git.server.com [420.420.555.555] port 22.
debug1: Connection established.
debug1: identity file /Users/adam/.ssh/id_rsa type 1
debug1: identity file /Users/adam/.ssh/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-3ubuntu1
debug1: match: OpenSSH_6.0p1 Debian-3ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr 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: Server host key: RSA 96:cc:........
debug1: Host 'git.server.com' is known and matches the RSA host key.
debug1: Found key in /Users/adam/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/adam/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to git.server.com ([257.257.257.257]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Sending environment.
debug1: Sending env LANG = en_GB.UTF-8
Welcome to GitLab, !
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2512, received 2968 bytes, in 0.5 seconds
Bytes per second: sent 5567.4, received 6578.0
debug1: Exit status 0

Однако выполнение этой команды не выполняется

ssh [email protected] "ls /home/git/repositories/adam/my-repo.git"

person Adam Elsodaney    schedule 16.04.2013    source источник
comment
Какую версию GitLab вы используете?   -  person VonC    schedule 16.04.2013
comment
@ВонС 5.0. Это в названии. Для подтверждения я проверил ветку 5-0-stable   -  person Adam Elsodaney    schedule 16.04.2013
comment
Извините за вопрос, я должен был прочитать заголовок ;) 5.0 означает отсутствие gitolite. Но его замена, gitlab-shell, отклонила бы любую команду, отличную от git, что объясняет, почему ls потерпит неудачу.   -  person VonC    schedule 16.04.2013


Ответы (1)


Похоже на текущую ошибку 3424.

Вам необходимо убедиться:

  • Приложение Gitlab (с потребителями sidekiq) и Redis запущены
  • конфиг правильный

Пример проблемы с конфигурацией:

Немного расслабившись и просмотрев все свои файлы конфигурации, я нашел свою проблему, в которой, конечно, была моя вина.

Недолго думая, пока я настраивал свой сервер, в файле /etc/hosts я добавил имя x.m.com к петлевому IP-адресу (127.0.0.1).
Таким образом, любые сетевые вызовы, выполняемые на моем локальном сервере с этим именем, будут идти на этот IP-адрес. вместо IP-адреса, к которому NginX фактически был привязан для сервера GitLab.

Другой пример:

Я смог решить свою проблему, изменив конфигурацию nginx для прослушивания *:80 вместо определенного IP-адреса. Видимо из-за брандмауэра разные внутренние и внешние IP.

listen *:80 default_server;

Эта последняя ошибка конфигурации подробно обсуждается в issues/3384.


Последний выпуск 5.1 помогает, как сообщает OP Adam-E в комментарии, выполнив следующие действия:

  • заменил Apache2 на nginx,
  • сделал чистую установку только что выпущенной стабильной версии GitLab 5.1 и
  • усеченный /home/git/.ssh/authorized_keys и
  • прочитал мой открытый ключ.

С этого последнего шага он начал работать.

person VonC    schedule 16.04.2013
comment
В моем случае я использую Apache с Passenger. Он отлично работает, и у меня не было этой проблемы с другой установкой GitLab + Passenger. Не уверен, что отличается в этом случае. Я продолжу расследование. - person Adam Elsodaney; 17.04.2013
comment
@Adam-E Я сам использую Apache с пассажиром: github. com/VonC/compileEverything/blob/master/gitlab/ Но эта ошибка была связана с портом, который вы слушаете (Apache или NGiNX). - person VonC; 17.04.2013
comment
Хороший проект. Я снял его. Но почему номер порта, который прослушивает Apache, не является проблемой для клонирования через HTTPS, а через SSH? Для справки, у меня есть <VirtualHost *:443> ServerName git.server.com в конфигурации моего сайта. - person Adam Elsodaney; 18.04.2013
comment
@Adam-E в основном потому, что имя сервера не удалось разрешить, а с «*» проблем с разрешением нет: он прослушивает любое имя. - person VonC; 18.04.2013
comment
Кажется, теперь я начинаю понимать. Кстати, API возвращает 404 для этого действия ssh push. - person Adam Elsodaney; 18.04.2013
comment
Я заменил Apache2 на nginx, выполнил чистую установку только что выпущенной стабильной версии GitLab 5.1 и усекал /home/git/.ssh/authorized_keys и прочитал свой открытый ключ. С этого последнего шага он начал работать. - person Adam Elsodaney; 24.04.2013
comment
@ Адам-Э Отлично. Я включил ваш вывод в ответ для большей наглядности. - person VonC; 24.04.2013