GitLab exige que le mot de passe soit git @ localhost soit transmis à un dépôt
J'essaie de faire fonctionner GitLab sur mon serveur. J'ai suivi les instructions d'installation sur la page gitlab github et tout s'est bien passé.
Le problème est, lorsque je crée un repo et que je tente de
Sudo git Push -u Origin master
Je suis invité à entrer le mot de passe de git @ localhost:
L'utilisateur git n'a pas de mot de passe, donc c'est un problème.
D'autres personnes ayant rencontré ce problème ont suggéré d'ajouter git à AllowedUsers dans ma conf. Sshd, mais je n'ai pas de champ AllowedUsers dans celui-ci, donc cela ne semble pas être un problème.
Je suis encore assez novice en matière de SSH, je pense donc que c'est un problème de clé SSH, bien que j'aie essayé d'ajouter toutes les clés SSH pertinentes à /home/git/.ssh/authorized_keys et de vérifier qu'il n'y avait pas de sauts de ligne dans le fichier. .
Juste pour votre information, mon installation passe complètement le test fourni dans le wiki de gitlab:
Sudo -u gitlab bundle exec rake gitlab:app:status Rails_ENV=production
Toutes les suggestions très appréciées!
MODIFIER
Alors, j'ai finalement contourné cela en m'engageant simplement dans un dépôt d'une machine différente. Dans l’état actuel des choses, j’ai été connecté à SSHed sur la même machine que gitlab. Dès que j'ai essayé de m'engager à partir d'une machine autre que l'hôte, cela a très bien fonctionné. Donc, cela peut être une solution pour certaines personnes (c'est pour nous, car nous développons sur des machines séparées de celles de nos serveurs).
Il s'agit toujours d'un problème ouvert pour quiconque tente d'héberger et de développer sur le même ordinateur que celui rencontré auparavant.
TL; DR
Les clés stockent gitlab DB et gitolite. Vous devez utiliser le dossier gitolite-admin.git fabriqué en usine, ne pas utiliser votre sauvegarde! Et reconstruire les clés pour gitolite ultérieurement avec la mise à jour Commande keys. (met à jour les clés déjà enregistrées dans gitlab db en gitolite)
Sudo -u gitlab -H bundle exec rake gitlab:gitolite:update_keys Rails_ENV=production
Probablement, c'est parce qu'il y a un problème avec les clés gitolite qui ne sont pas enregistrées correctement. Ces clés (pour le login) sont conservées séparément par gitlab et gitolite. Pour tirer/pousser, c'est utiliser les clés sauvegardé à l'intérieur de gitolite. (git/repositories/gitolite-admin.git/index, git/.gitolite/keydir, git/.ssh/allowed_keys)
gitlab devrait normalement aider à sauvegarder les clés importées sur le Web dans les fichiers gitolite. Cependant, pour certaines raisons, cela a échoué. Les clés ne sont pas correctement enregistrées dans gitolite, le client/serveur ne parvient pas à utilisez les clés et fallback au mot de passe.
Vous devez vérifier et réparer les clés enregistrées dans gitolite pour corriger les problèmes.
consultez pour plus d'informations. https://groups.google.com/forum/?fromgroups=#!topic/gitlabhq/X0z_9l7L7A8
Si l'installation s'est bien déroulée, cela signifie que votre gitlab est capable de cloner le dépôt gitolite-admin sans problème.
Mais vous dites qu'il passe la vérification de statut, ce qui signifie que vous utilisez, pour la connexion SSH, un compte nommé 'gitlab'.
Cela signifie également que tout client devra ssh avec le même compte 'gitlab', et non 'git'.
Donc, si votre clé ssh a été ajoutée via l’interface de gitlab, vous pouvez alors git cloner/git Push vers un nom distant Origin qui aurait pour adresse «gitlab@server».
Pour en déboguer d'autres, consultez d'autres astuces mentionnées dans " Configuration de Git Remote SSH (git-upload-pack/git-receive-pack) ":
Si vous ne pouvez pas transmettre localement (sur le serveur lui-même, c'est-à-dire 'localhost'), essayez au moins:
ssh -vvvT gitlab@localhost
Il ne devrait pas nécessiter de mot de passe, puisque /home/gitlab/.ssh/id_rsa et /home/gitlab/.ssh/id_rsa.pub existent tous les deux.
J'ai reçu le même mot de passe Invite. Mon problème était que j'avais limité l'utilisation de ssh à seulement quelques utilisateurs. J'ai ajouté l'utilisateur git à la liste AllowUsers sshd_config, et tout a bien fonctionné.
Cela a commencé à m'arriver beaucoup ces derniers temps - pour les projets de travail, git me demandait mon email et mon mot de passe. Une fois entré, ça continue mais c'est ennuyant.
Je peux résoudre ce problème pour n'importe quelle application à laquelle j'ai accès avec:
git config remote.Origin.url [email protected]:user_org_or_co/repo_name_itself
par exemple.
git config remote.Origin.url [email protected]:smithw/bookmarkapp
Assurez-vous que votre profil gitlab a votre clé publique SSH. Connectez-vous à gitlab, accédez à votre profil et sélectionnez le bouton "Ajouter une clé publique". Copiez et collez le contenu de votre fichier "keyfile" dans la zone "Key". Certaines versions de gitlab contenaient un bogue qui empêchait lors de l'ajout de votre clé publique de mettre à jour le fichier allowed_keys. Vérifiez (mais n’ajoutez pas manuellement) que votre clé publique se trouve dans le fichier allowed_keys après l’avoir ajoutée à votre profil. Si ce n'est pas le problème, alors l'une des réponses précédentes aidera peut-être.
sur le serveur git, éditez /etc/ssh/sshd_config
décommentez les lignes suivantes sous la section d'authentification ou ajoutez-les:
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
donnez à votre serveur un cycle d'alimentation, puis lancez gitlab
C'est peut-être trop simple, mais j'ai eu le même problème. Je suppose que c'est parce qu'il a choisi localhost comme nom de domaine.
Cela a fonctionné lorsque je me suis connecté à partir d'un autre ordinateur à mon ordinateur localhost, puis j'ai essayé de valider. C'est assez bête mais ça vaut le coup d'essayer.
J'ai rencontré le même problème récemment et j'ai découvert que le problème pour moi était que SELinux empêchait sshd d'accéder au fichier registered_keys du répertoire de données de gitlab /var/opt/gitlab/.
Pour résoudre ce problème, éditez /etc/selinux/targeted/contexts/files/file_contexts.homedirs et ajoutez la ligne:
/var/opt/gitlab/\.ssh/.* system_u:object_r:ssh_home_t:s0
Puis lancez:
$ restorecon -Rv /var/opt/gitlab
Source: https://serverfault.com/questions/50573/selinux-preventing-passwordless-ssh-login
J'ai rencontré un problème présentant des symptômes similaires. Mon problème était que j'ai deux ordinateurs derrière un routeur. Le routeur est configuré pour transférer le trafic SSH vers l'avant (port 22) vers l'ordinateur 1. Gitlab est installé sur l'ordinateur 2. J'utilise un domaine et une adresse IP publique pour se connecter. Lorsque j'appuie, le trafic SSH est dirigé vers l'ordinateur 1. Il y a un utilisateur git sur l'ordinateur 1 simplement après avoir installé git. L'ordinateur 1 me demande le mot de passe de l'utilisateur git.
Mon installation a également passé tous les contrôles.
Je ne sais pas si vous rencontrez le même problème, mais les symptômes sont exactement les mêmes, alors j'ai pensé que cela pourrait aider.
Vos utilisateurs git et gitlab n'ont pas de mot de passe?
Comment est le sshd_config?
vérifie si cette ligne est dans le fichier: PermitEMptyPassword Yes
Quoi qu'il en soit, je suppose que c'est dangereux, dans mon installation, j'ai mis ce 'Oui', ce clone, puis je conserve l'ancienne configuration ... Lorsque le clonage de la clé ssh_key est enregistré par l'utilisateur git, il ne demandera plus de mot de passe. .
Mais à présent, je rencontre une autre erreur, lorsque je passe à Push, pour chaque nouvel utilisateur, nous devons reconfigurer ssh pour une permission Push vide, puis conserver la configuration.
(Je n'ai toujours pas testé cette méthode car j'ai découvert que mon gitlab ne crée pas le dépôt dans l'utilisateur git: /)
Il y a un coché pour cela ici .
Pour déterminer la cause du problème, consultez les journaux sur le serveur via Sudo grep sshd /var/log/auth.log.
Jusqu'au 13 décembre 2013, commit b24d5d, le problème venait de la machine de développement Vagrant en raison de excess of permissions for .ssh/. Vous devez avoir:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
ou ssh refuse d'établir la connexion rsa et Sudo grep sshd /var/log/auth.log indique:
Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys
Le problème a été résolu en réglant sshd en mode non strict pour le développement, ce qui lui permet de fonctionner correctement même si ses autorisations sont trop libres.
Si vous rencontrez ce problème avec Bitnami ou toute autre configuration qui souhaite le résoudre rapidement, utilisez simplement le chemin complet.
git clone git@server_adress:/full/path/to/project.git
édition: J'ai oublié de mentionner, il est très important de vérifier si vous avez ajouté les clés SSH à git-lab via la page Web.
Je me suis mêlé à ça une fois. Lorsque vous utilisez Sudo git, cela signifie que le git est lancé en tant que root. La question serait: avez-vous créé la clé SSH pour root et l'avez-vous insérée dans Gitlab?
Je suppose que vous avez créé votre clé SSH sans Sudo (ce qui est pour votre compte normal), mettez le publickey SSH dans Gitlab, puis exécutez Sudo git.
Vous pouvez essayer de lancer git sans la Sudo. Et si vous rencontrez des problèmes d’autorisation de dossier, ce qui vous a amené à utiliser Sudo en premier lieu, essayez d’accorder à votre compte utilisateur l’accès à ce dossier. Ou peut-être essayez-vous normalement dans un dossier pour lequel vous disposez d'une autorisation d'écriture.
Cela signifie que le serveur gitlab ssh n'a pas été configuré correctement.
Éditez /etc/ssh/sshd_config et assurez-vous que:
PasswordAuthentication no
ChallengeResponseAuthentication no
Cela devrait imposer uniquement les connexions ssh, ce qui constitue également une bonne mesure de sécurité. Cela est déjà activé par défaut dans de nombreuses distributions plus récentes.
Ne me demandez pas si vous êtes bloqué à l'extérieur, clairement SO n'est pas l'endroit où demander comment configurer et utiliser une paire de clés privée/publique.