Quali "diritti di accesso" potrebbero bloccare l'accesso a un repository gitlab?

Sto cercando di installare gitlab (6.5.1) su un server pulito e nuovo. Tutto sembra funzionare, ma git non è in grado di eseguire alcun progetto. Seguendo i comandi dalla pagina del progetto appena creato e spingendo al telecomando tramite ssh si ottiene:

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

Questo sembra essere un problema abbastanza comune. Sfortunatamente sembra avere una serie di potenziali cause e nessuna di queste sembra corrispondere. Dal numero 3424 di una vecchia versione e varie altre fonti online ho visto e verificato i seguenti suggerimenti:

• Tasti SSH rimanenti

  Questa è una configurazione pulita senza avanzi. La mia chiave è stata aggiunta correttamente al file delle chiavi autorizzate ed è l'unica elencata.

• L'esecuzione di ssh con la registrazione di debug mostra errori relativi alle variabili di ambiente Ruby.

  Il mio viene pulito. Il debug SSH mostra una connessione riuscita. Tutto ciò che riguarda l'handshaking di autenticazione è normale, quindi questa è la fine dell'output:

  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
  

• Problemi con l'ambiente gitlab-shell.

  A differenza di molti altri con lo stesso messaggio di errore sopra, il mio script di controllo gitlab-shell restituisce un buono stato di salute:

  % 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
  

• Riavvia {unicorno, sidekiq, redis}

  I rapporti secondo cui il riavvio di uno o più servizi lo risolvono non sembrano applicarsi qui. Questo non è un problema intermittente risolto dal rilancio di un demone.

• Il repository non viene creato fisicamente

  Ma è. La prima volta ogni volta, il repository bare git ~gitlab/repositories/username/reponame.gitviene creato ogni volta e sembra avere i permessi corretti.

• Gitlab-shell non può parlare con il server API perché A) problemi DNS, B) errata associazione ip / porta / interfaccia C) non avendo / avendo una barra finale.

  Lo script di controllo indica che l'accesso all'API è corretto.

  Non sto eseguendo nginx, quindi il problema di associazione ip predefinito relativo a questo è n / a.

  Ho provato entrambi *:8080e 127.0.0.1:8080per il valore di ascolto in unicorn.yml.

  Oltre a ciò, ho provato varie iterazioni di localhost, 127.0.0.1 e il nome di dominio completo (che sta risolvendo bene il DNS) con e senza barre di scorrimento shell.ymlinutili. Ho anche provato a collegarlo direttamente al server unicorno sulla porta 8080 anziché all'host Apache SSL / proxy sulla porta 80. Niente sembra fare alcuna differenza. Il mio certificato non è autofirmato e funziona bene per i browser, ma ho provato self_signed_cert: truecomunque a impostare . Niente.

• I percorsi git segnalati sono errati, aggiungi il percorso completo dalla home page dell'utente gitlab.

  Questo sembra un suggerimento legittimo se la gitlab-shell non sta già facendo affari con le scimmie per correggerlo già, ma ho provato a cambiare git remote add origin gitlab@server:username/reponame.gita `` git remote add origin gitlab @ server: repository / nomeutente / reponame.git` inutilmente. Stesso errore

Questa sembra essere la litania di soluzioni suggerite, ma nessuna di queste sembra giusta. Nota Sono in grado di eseguire il push su http. Il prompt di accesso accetta il mio nome utente e la mia password ldap e accetta un push. Questo è solo un problema nel tentativo di utilizzare SSH. Testare solo la parte di login ssh con ssh -T gitlab@serverfunziona correttamente.

Cos'altro potrebbe causare questo errore?

Come si fa a eseguire il debug di un tale problema in gitlab? Non sembra esserci nulla di rilevante in ~gitlab/gitlab-shell/gitlab-shell.log. Dove si trova un messaggio di errore più informativo?

Sono abbastanza sicuro che tu abbia un problema di configurazione tra SSH e il sistema a causa di questo messaggio di debug SSH:

client_input_channel_req: channel 0 rtype eow@openssh.com reply 0

Ricevi questo messaggio immediatamente dopo un'autenticazione riuscita e nessun messaggio da bash, il che significa che nessun programma è stato avviato dopo il login.

Guarda nel tuo file passwd se hai le giuste impostazioni per l'utente gitlab:

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

Verifica che bash non abbia nulla di strano nei file di configurazione come

• bash.bashrc
• .profilo
• .bashrc

Quindi vai al livello superiore: Gitlab-shell Verifica che /path/to/gitlab/.ssh/authorized_keys abbia la configurazione seguente:

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

con / path / to / gitlab / gitlab-shell / bin / gitlab-shell di proprietà dell'utente ed eseguibile gitlab.

Puoi essere sicuro che gitlab-shell è completamente operativo avviando il comando:

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

Se il login remoto funziona davvero e correttamente connesso alla shell gitlab, dovresti ricevere lo stesso messaggio di benvenuto (ma abbinato all'utente di cui hai usato il tasto ssh per effettuare il login) prima di scaricarti se provi ad accedere in remoto.

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

Nessun messaggio qui probabilmente indica che ssh non ti sta collegando a gitlab.

Infine, controlla la tua configurazione di gitlab-shell (config.yml) e verifica se:

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

ed eventualmente :

    self_signed_cert: false

Ho avuto lo stesso problema e dopo giorni di ricerche su Google con Stack Overflow ho finalmente trovato il mio problema. Volevo che questo per iscritto fosse collegato a Gitlab nel caso in cui qualcun altro avesse avuto lo stesso problema.

Ho trovato la mia soluzione qui: /programming/17307154/git-bash-push-to-bitbucket-ignores-ssh-key

Sono su Windows e il problema era che Git Bash stava cercando di ottenere la posizione della sua chiave SSH da plink.exe, che è installato con Putty.

La soluzione era eliminare la variabile di ambiente GIT_SSH. Quindi tutto ha funzionato.

Spero che questo aiuti qualcuno là fuori.