Quels «droits d'accès» pourraient bloquer l'accès à un référentiel gitlab?


14

J'essaie de configurer gitlab (6.5.1) sur un nouveau serveur propre. Tout semble fonctionner, mais git est incapable de pousser vers n'importe quel projet. Suivre les commandes de la page de projet nouvellement créée et pousser vers la télécommande via ssh donne:

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

Cela semble être un problème assez courant. Malheureusement, il semble avoir un certain nombre de causes potentielles et aucune ne semble correspondre. Depuis le numéro 3424 d'une ancienne version et de diverses autres sources en ligne, j'ai vu et vérifié les suggestions suivantes:

  • Clés ssh restantes

    Il s'agit d'une configuration propre sans restes. Ma clé a été ajoutée correctement au fichier de clés autorisées et est la seule répertoriée.

  • L'exécution de ssh avec la journalisation du débogage affiche des erreurs liées aux variables d'environnement Ruby.

    Le mien est propre. Le débogage SSH montre une connexion réussie. Tout ce qui concerne la négociation de l'authentification est normal, alors c'est la fin de la sortie:

    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
    
  • Problèmes avec l'environnement gitlab-shell.

    Contrairement à beaucoup d'autres avec le même message d'erreur ci-dessus, mon script de vérification gitlab-shell renvoie un bilan de santé propre:

    % 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
    
  • Redémarrez {unicorn, sidekiq, redis}

    Les rapports selon lesquels le redémarrage d'un ou de plusieurs services efface ce problème ne semblent pas s'appliquer ici. Ce n'est pas un problème intermittent que la relecture d'un démon corrige.

  • Le dépôt n'est pas créé physiquement

    Mais il est. La première fois à chaque fois, le dépôt nu git ~gitlab/repositories/username/reponame.gitest créé à chaque fois et semble avoir les autorisations correctes.

  • Gitlab-shell ne peut pas parler au serveur API car A) des problèmes DNS, B) une liaison ip / port / interface incorrecte C) ne pas avoir / avoir une barre oblique de fin.

    Le script de vérification indique que l'accès à l'API est correct.

    Je n'exécute pas nginx, donc le problème de liaison IP par défaut lié à cela est n / a.

    J'ai essayé les deux *:8080et 127.0.0.1:8080pour la valeur d'écoute unicorn.yml.

    Au-delà de cela, j'ai essayé diverses itérations de localhost, 127.0.0.1 et le nom de domaine complet (qui résout très bien le DNS) avec et sans barres obliques en shell.ymlvain. J'ai également essayé de câbler ceci directement au serveur licorne sur le port 8080 au lieu de l'hôte Apache SSL / proxy sur le port 80. Rien ne semble faire de différence. Mon certificat n'est pas auto-signé et fonctionne bien pour les navigateurs, mais j'ai self_signed_cert: truequand même essayé de le configurer . Rien.

  • Les chemins git signalés sont incorrects, ajoutez un chemin qualifié complet depuis la page d'accueil de l'utilisateur gitlab.

    Cela semble être une suggestion légitime si le gitlab-shell ne fait pas quelque chose de singe pour corriger cela déjà, mais j'ai essayé de changer git remote add origin gitlab@server:username/reponame.giten `` git remote add origin gitlab @ server: repositories / username / reponame.git` en vain. Même erreur.

Cela semble être la litanie de solutions suggérées, mais aucune ne semble juste. Notez que je peux pousser sur http. L'invite de connexion accepte mon nom d'utilisateur et mon mot de passe LDAP et accepte un push. Ce n'est qu'un problème en essayant d'utiliser SSH. Tester juste la partie de connexion ssh avec ssh -T gitlab@serverfonctionne très bien.

Quoi d'autre pourrait être à l'origine de cette erreur?

Comment procéder pour déboguer un tel problème dans gitlab? Il ne semble rien y avoir de pertinent du tout ~gitlab/gitlab-shell/gitlab-shell.log. Où trouver un message d'erreur plus informatif?


Quelle est la sortie de: "ssh -vv gitlab @ server" ??
DrGkill

@DrGkill Rien d'intéressant (à mes yeux), voyez par vous-même .
Caleb

Voyez dans votre sshd_config si gitlab est autorisé pour la connexion externe. Je dirais 2 coupables possibles: SSH ou gitlab-shell. Que dit auth.log lorsque gitlab se connecte?
DrGkill

@DrGkill J'ai vérifié cela (et s'il n'était pas autorisé à se connecter à l'extérieur par sshd ou pam, les journaux que je vous ai montrés ci-dessus n'auraient pas affiché de notification d'authentification réussie). SSH se connecte très bien. Les journaux côté serveur montrent une authentification réussie, qu'une session a été ouverte, des trucs systemd sur la configuration de l'env de l'utilisateur, puis "une déconnexion reçue de <ip distant>" et quelques autres trucs sur le nettoyage de la session.
Caleb

Réponses:


7

Je suis sûr que vous avez un problème de configuration entre SSH et le système à cause de ce message de débogage SSH:

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

Vous recevez ce message immédiatement après une authentification réussie et aucun message de bash ce qui signifie qu'aucun programme n'a été lancé après la connexion.

Regardez dans votre fichier passwd si vous avez les bons paramètres pour l'utilisateur gitlab:

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

Vérifiez que bash n'a rien de bizarre dans les fichiers de configuration tels que

  • bash.bashrc
  • .profil
  • .bashrc

Montez ensuite au niveau supérieur: Gitlab-shell Vérifiez que /path/to/gitlab/.ssh/authorized_keys a la configuration ci-dessous:

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

avec / path / to / gitlab / gitlab-shell / bin / gitlab-shell appartenant à l'utilisateur gitlab et exécutable.

Vous pouvez être sûr que gitlab-shell est pleinement opérationnel en lançant la commande:

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

Si la connexion à distance fonctionne et est correctement connectée au gitlab-shell, vous devriez obtenir le même message de bienvenue (mais correspondant à l'utilisateur dont vous avez utilisé la clé ssh pour vous connecter) avant de vous décharger si vous essayez de vous connecter à distance.

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

Aucun message ici n'indique probablement que ssh ne vous connecte pas du tout à gitlab.

Enfin, vérifiez votre configuration gitlab-shell (config.yml) et vérifiez si:

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

et éventuellement :

    self_signed_cert: false

Doh. <head-desk> Vous étiez sur la bonne voie depuis le début. L'utilisateur gitlab était affecté /bin/false. Soit le package Arch ne définit pas le shell correctement lors de l'ajout de cet utilisateur, soit je l'ai cassé quelque part dans le processus d'implémentation de l'authentification LDAP sur ce système. Merci pour tout l'effort.
Caleb

ty pour la réponse, m'a aidé à déboguer. Un autre problème est que lorsque le transfert de clé ssh est activé, vous envoyez la mauvaise clé à gitlab qui ne peut pas vous identifier. Lorsque vous entrez dans gitlab, vous obtiendrez également Welcome Anonymous. Désactivez simplement le transfert de clé sur votre jumpserver avec ssh -a
tommics

J'ai eu le même problème que Caleb, et j'ai également constaté par moi-même que pour le faire fonctionner, il fallait définir un shell au lieu de / bin / {false, true, nologin}. Mais en réalité, l'utilisateur est créé sans shell exprès lors de l'installation (voir: gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/… ) sudo adduser --disabled-login --gecos 'GitLab' git. Il devrait donc fonctionner sans coque. Je cherche toujours une autre solution.
Huygens

0

J'ai eu ce même problème et après des jours de recherche sur Google et de recherche de débordement de pile, j'ai finalement trouvé mon problème. Je voulais que cela soit connecté par écrit à Gitlab au cas où quelqu'un d'autre aurait le même problème.

J'ai trouvé ma solution ici: /programming/17307154/git-bash-push-to-bitbucket-ignores-ssh-key

Je suis sous Windows et le problème était que Git Bash essayait d'obtenir son emplacement de clé SSH à partir de plink.exe, qui est installé avec Putty.

La solution a été de supprimer la variable d'environnement GIT_SSH. Ensuite, tout a fonctionné.

J'espère que cela aide quelqu'un là-bas.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.