Какие "права доступа" могут блокировать доступ к хранилищу gitlab?

Я пытаюсь настроить gitlab (6.5.1) на свежий чистый сервер. Кажется, все работает, но git не может перейти ни в один проект. Следование командам со страницы недавно созданного проекта и отправка на удаленный компьютер через ssh дает:

$ git push -u origin master
fatal: Could not read from remote repository.

Please make sure you have the correct access
rights and the repository exists.

Это кажется довольно распространенной проблемой. К сожалению, кажется, что у этого есть несколько потенциальных причин, и ни одна из них, кажется, не совпадает Начиная с номера 3424 старого выпуска и различных других источников в Интернете, я видел и проверял следующие предложения:

• Остаток ключей SSH

  Это чистая установка без остатков. Мой ключ был добавлен в файл авторизованных ключей правильно и является единственным в списке.

• Запуск ssh с ведением журнала отладки показывает ошибки, связанные с переменными среды Ruby.

  Моя приходит чистой. Отладка SSH показывает успешное соединение. Все, что касается аутентификации, является нормальным, тогда это конец вывода:

  debug1: Sending command: git-receive-pack 'username/reponame.git'
  debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
  debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
  debug1: channel 0: free: client-session, nchannels 1
  debug1: fd 0 clearing O_NONBLOCK
  debug1: fd 1 clearing O_NONBLOCK
  

• Проблемы со средой gitlab-shell.

  В отличие от многих других с таким же сообщением об ошибке, приведенным выше, мой скрипт проверки gitlab-shell возвращает чистый счет здоровья:

  % sudo -u gitlab -H ~gitlab/gitlab-shell/bin/check   
  Check GitLab API access: OK
  Check directories and files: 
          /var/lib/gitlab/repositories: OK
          /var/lib/gitlab/.ssh/authorized_keys: OK
  Test redis-cli executable: redis-cli 2.8.5
  Send ping to redis server: PONG
  

• Restart {единорог,sidekiq,redis}

  Сообщения о том, что перезапуск одной или нескольких служб устраняет эту проблему, похоже, здесь не применяются. Это не временная проблема, возникающая при выпуске исправлений демона.

• Репо не создается физически

  Но это. Первый раз каждый раз, голый репозиторий ~gitlab/repositories/username/reponame.git создается каждый раз и, кажется, имеет правильные разрешения.

• Gitlab-shell не может общаться с сервером API, потому что A) проблемы с DNS, B) неправильная привязка ip/port/interface C) отсутствие / наличие косой черты.

  Сценарий проверки говорит, что доступ к API в порядке.

  Я не запускаю nginx, поэтому проблема связывания с ip по умолчанию связана с n/a.

  Я пробовал оба *:8080 а также 127.0.0.1:8080 для значения прослушивания в unicorn.yml,

  Кроме того, я пробовал различные итерации localhost, 127.0.0.1 и полностью квалифицированное доменное имя (которое прекрасно разрешается DNS) с и без конечных слешей. shell.yml но безрезультатно. Я также попытался подключить это напрямую к серверу единорога на порту 8080 вместо хоста Apache SSL / proxy на порту 80. Кажется, ничего не имеет значения. Мой сертификат не подписан самостоятельно и работает нормально для браузеров, но я попытался установить self_signed_cert: true тем не мение. Ничего такого.

• Сообщенные пути git неверны, добавьте полный путь из дома пользователя gitlab.

  Это кажется правдоподобным предложением, если gitlab-shell не занимается обезьяньим бизнесом, чтобы исправить это, но я попытался изменить git remote add origin gitlab@server:username/reponame.git в ``git remote 'добавьте origin gitlab@server:repositories/username/reponame.git` безрезультатно. Та же ошибка

Кажется, это перечень предлагаемых решений, но ни одно из них не кажется правильным. Обратите внимание, я могу нажать http. Приглашение для входа в систему принимает мое имя пользователя и пароль ldap и принимает push. Это только проблема при попытке использовать SSH. Тестирование только части входа ssh с ssh -T gitlab@server работает отлично.

Что еще может быть причиной этой ошибки?

Как можно отладить такую ​​проблему в gitlab? Кажется, в ~gitlab/gitlab-shell/gitlab-shell.log, Где найти более информативное сообщение об ошибке?