Jakie „prawa dostępu” mogą blokować dostęp do repozytorium gitlab?

Próbuję zainstalować gitlab (6.5.1) na świeżym, czystym serwerze. Wygląda na to, że wszystko działa, ale git nie jest w stanie wykonać żadnego projektu. Postępowanie zgodnie z poleceniami z nowo utworzonej strony projektu i przekazywanie do pilota za pomocą ssh daje:

$ 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.

Wydaje się, że jest to dość powszechny problem. Niestety wydaje się, że ma wiele potencjalnych przyczyn i żadna z nich nie pasuje. Od wydania 3424 na starej wersji i różnych innych źródłach online widziałem i sprawdziłem następujące sugestie:

• Pozostawione klucze ssh

  To czysta konfiguracja bez resztek. Mój klucz został poprawnie dodany do pliku autoryzowanych kluczy i jest jedynym wymienionym na liście.

• Uruchomienie ssh z rejestrowaniem debugowania pokazuje błędy związane ze zmiennymi środowiska Ruby.

  Mój jest czysty. Debugowanie SSH pokazuje pomyślne połączenie. Wszystko w uzgadnianiu uwierzytelnienia jest normalne, to jest koniec wyniku:

  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 [email protected] reply 0
  debug1: channel 0: free: client-session, nchannels 1
  debug1: fd 0 clearing O_NONBLOCK
  debug1: fd 1 clearing O_NONBLOCK
  

• Problemy ze środowiskiem powłoki gitlab.

  W przeciwieństwie do wielu innych z tym samym komunikatem o błędzie powyżej, mój skrypt sprawdzający gitlab-shell zwraca czysty stan zdrowia:

  % 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 {jednorożec, sidekiq, redis}

  Raporty, że ponowne uruchomienie jednej lub więcej usług usuwa to, nie wydają się mieć tutaj zastosowania. To nie jest sporadyczny problem, który wprowadza poprawki demona.

• Repo nie jest tworzone fizycznie

  Ale to jest. Za każdym razem po raz pierwszy nagie repozytorium git ~gitlab/repositories/username/reponame.gitjest tworzone za każdym razem i wydaje się mieć odpowiednie uprawnienia.

• Gitlab-shell nie może komunikować się z serwerem API, ponieważ A) problemy z DNS, B) błędne powiązanie adresu IP / portu / interfejsu C) brak / ukośnik końcowy.

  Skrypt kontrolny mówi, że dostęp do interfejsu API jest w porządku.

  Nie używam nginx, więc domyślnym związanym z tym problemem wiązania IP jest nie dotyczy.

  Próbowałem obu *:8080i 127.0.0.1:8080dla wartości podsłuchu w unicorn.yml.

  Poza tym wypróbowałem różne iteracje localhost, 127.0.0.1 i w pełni kwalifikowanej nazwy domeny (czyli DNS dobrze rozwiązującej) z lub bez ukośników shell.ymlbezskutecznie. Próbowałem również podłączyć to bezpośrednio do serwera jednorożca na porcie 8080 zamiast hosta Apache SSL / proxy na porcie 80. Nic nie wydaje się mieć znaczenia. Mój certyfikat nie jest samopodpisany i działa dobrze w przeglądarkach, ale mimo to próbowałem go ustawić self_signed_cert: true. Nic.

• Podane ścieżki git są nieprawidłowe, dodaj pełną ścieżkę z domu użytkownika gitlab.

  To wydaje się słuszną sugestią, jeśli powłoka gitlab nie robi już małpiego biznesu, aby to naprawić, ale próbowałem zmienić git remote add origin gitlab@server:username/reponame.gitna `` git zdalne dodawanie pochodzenia gitlab @ server: repositories / username / reponame.git`` bezskutecznie. Ten sam błąd.

To wydaje się być litanią proponowanych rozwiązań, ale żadne z nich nie wydaje się słuszne. Uwaga: Jestem w stanie przesłać http. Monit logowania akceptuje moją nazwę użytkownika i hasło ldap oraz akceptuje push. Jest to tylko problem przy próbie użycia SSH. Testowanie tylko części logowania ssh z działaniem ssh -T gitlab@serverdziała poprawnie.

Co jeszcze może powodować ten błąd?

Jak można debugować taki problem w gitlab? Wydaje się, że w ogóle nie ma nic istotnego ~gitlab/gitlab-shell/gitlab-shell.log. Gdzie można znaleźć bardziej informacyjny komunikat o błędzie?

Jestem prawie pewien, że masz problem z konfiguracją między SSH a systemem z powodu tego komunikatu debugowania SSH:

client_input_channel_req: channel 0 rtype [email protected] reply 0

Otrzymujesz tę wiadomość natychmiast po udanym uwierzytelnieniu i nie ma wiadomości od bash, co oznacza, że ​​żaden program nie został uruchomiony po zalogowaniu.

Sprawdź w pliku passwd, czy masz odpowiednie ustawienia dla użytkownika gitlab:

gitlab:x:1011:1012:GitLab,,,:/path/to/gitlab:/bin/bash

Sprawdź, czy bash nie ma dziwnych rzeczy w plikach konfiguracyjnych takich jak

• bash.bashrc
• .profil
• .bashrc

Następnie przejdź do wyższego poziomu: Gitlab-shell Sprawdź, czy /path/to/gitlab/.ssh/authorized_keys ma konfigurację poniżej:

command="/path/to/gitlab/gitlab-shell/bin/gitlab-shell key-2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa A...

z / path / to / gitlab / gitlab-shell / bin / gitlab-shell należący do użytkownika gitlab i wykonywalny.

Możesz być pewien, że gitlab-shell jest w pełni operacyjny, uruchamiając polecenie:

# /path/to/gitlab-shell/bin/gitlab-shell
Welcome to GitLab, Anonymous!

Jeśli zdalne logowanie faktycznie działa i jest poprawnie połączone z powłoką gitlab, powinieneś otrzymać tę samą wiadomość powitalną (ale dopasowaną do użytkownika, którego klucza ssh użyłeś do zalogowania się), zanim wyrzuci cię, jeśli spróbujesz zalogować się zdalnie.

$ ssh gitlab@server
Welcome to GitLab, <your user's full name>!
Connection to <server> closed.

Żadna wiadomość tutaj prawdopodobnie nie wskazuje, że ssh w ogóle nie łączy cię z gitlab.

Na koniec sprawdź konfigurację powłoki gitlab (config.yml) i sprawdź, czy:

http_settings:
    # trailing slash is important
    gitlab_url: "https://remote_server/"
    ca_file: /path/to/webserver/certificate.crt

i ostatecznie :

    self_signed_cert: false

Miałem ten sam problem i po wielu dniach googlingu i przeszukiwania przepełnienia stosu w końcu znalazłem swój problem. Chciałem to połączyć na piśmie z Gitlab na wypadek, gdyby ktoś miał ten sam problem.

Znalazłem moje rozwiązanie tutaj: /programming/17307154/git-bash-push-to-bitbucket-ignores-ssh-key

Jestem w systemie Windows i problem polegał na tym, że Git Bash próbował uzyskać lokalizację klucza SSH z pliku plink.exe, który jest instalowany z Putty.

Rozwiązaniem było usunięcie zmiennej środowiskowej GIT_SSH. Potem wszystko działało.

Mam nadzieję, że to pomoże komuś tam.