GitLab mot de passe utilisateur git
Je viens d'installer GitLab.
J'ai créé un projet appelé project-x.
J'ai créé peu d'utilisateurs et l'ai affecté au projet.
Maintenant, j'ai essayé de cloner:
git clone [email protected]:project-x.git
Cela m'a demandé un mot de passe.
Quel mot de passe dois-je utiliser?
Cela m'a demandé un mot de passe.
Cela ne devrait pas.
Si vous avez la bonne clé publique/privée représentant un utilisateur autorisé à accéder à project-x, alors gitlab ne vous demandera rien.
Mais cela suppose que ssh -vT [email protected] fonctionne en premier.
Pas strictement lié au scénario actuel. Parfois, lorsque vous êtes invité à entrer un mot de passe, c'est parce que vous avez ajouté le mauvais format * Origin (HTTPS au lieu de SSH).
Affichez vos informations de télécommande avec
git remote -v
si c'est avec l'adresse HTTP (S), c'est la commande pour la changer:
git remote set-url Origin [email protected]_domain.com/example-project.git
`* Le protocole HTTP (S) est généralement utilisé pour les pensions publiques, et l'authentification SSH est plus courante pour les projets internes où vous pouvez vous authentifier avec un fichier-clé ssh et une phrase secrète simple, au lieu d'un nom d'utilisateur fort + pass.
La solution de https://github.com/gitlabhq/gitlab-Shell/issues/46 a travaillé pour moi.
En définissant les autorisations:
chmod 700 /home/git/.ssh
chmod 600 /home/git/.ssh/authorized_keys
l'invite de mot de passe disparaît.
J'ai eu le même problème avec une clé de 4096 bits:
$ ssh-keygen -t rsa -C "GitLab" -b 4096
$ ssh -vT git @ gitlabhost
...
debug1: clé publique d'offre: /home/user/.ssh/id_rsa
debug1: authentifications qui peuvent continuer: publickey, mot de passe
debug1: tentative de clé privée: /home/user/.ssh/id_dsa
debug1: tentative de clé privée: /home/user/.ssh/id_ecdsa
debug1: Méthode d'authentification suivante: mot de passe
Le mot de passe de git @ gitlabhost:
Connexion fermée par l'hôte
Mais avec la clé 2048 bits (la taille par défaut), ssh se connecte à gitlab sans demander de mot de passe (après avoir ajouté la nouvelle clé de publication aux clés ssh de gitlab de l'utilisateur)
$ ssh-keygen -t rsa -C "GitLab"
$ ssh -vT git @ gitlabhost
Bienvenue sur GitLab, Joe User!
Cela peut arriver si l'hôte a un '-' dans son nom. (Même si cela est légal selon RFC 952 .) (Testé avec Git Bash sous Windows 10 avec git 2.13.2.)
ssh me demande un mot de passe pour tout hôte ayant un '-' dans son nom. Cela semblerait être purement un problème avec l'analyse du fichier de configuration ssh car l'ajout d'un alias à ~/.ssh/config (et l'utilisation de cet alias dans mes URL distantes git) a résolu le problème.
En d'autres termes, essayez de mettre quelque chose comme ceci dans votre C:/Users/{nom d'utilisateur}/.ssh/config
Host {a}
User git
Hostname {a-b.domain}
IdentityFile C:/Users/{username}/.ssh/id_rsa
et où vous avez une télécommande de la forme
Origin [email protected]:repo-name.git
changez l'URL pour utiliser le formulaire suivant
git remote set-url Origin git@a:repo-name.git
J'utilise un mac.gitlab est installé sur un serveur centos.
J'ai essayé toutes les méthodes ci-dessus et j'ai trouvé la réponse finale:
faux:
ssh-keygen -t rsa
droite:
ssh-keygen -t rsa -C "[email protected]" -b 4096
Pour ajouter encore une autre raison à la liste ... dans mon cas, j'ai constaté que ce problème était dû à un problème d'autorisations SELinux sur le serveur. Cela vaut la peine de vérifier si votre serveur exécute Fedora/CentOS/Red Hat. Pour tester ce scénario, vous pouvez exécuter:
Client: ssh -vT git@<gitlab-server> - demande le mot de passe
Serveur : Sudo setenforce 0
Client: ssh -vT git@<gitlab-server> - réussit
Serveur : Sudo setenforce 1
Dans mon cas, le fichier authorized_keys de l'utilisateur gitlab/git avait le mauvais contexte de fichier SELinux et le service ssh se voyait refuser l'autorisation de le lire. J'ai corrigé ceci du côté serveur comme suit:
Sudo semanage fcontext -a -t ssh_home_t /gitlab/.ssh/
Sudo semanage fcontext -a -t ssh_home_t /gitlab/.ssh/authorized_keys
Sudo restorecon -F -Rv /gitlab/.ssh/
Et j’ai alors pu git clone du côté client comme prévu.
Dans mon cas, j'utilisais une paire de clés sans les noms par défaut id_rsa et id_rsa.pub.
Produire des clés avec ces noms a résolu le problème et je l’ai trouvé en regardant la sortie de ssh -vT my_gitlab_address. Fait étrange: cela fonctionnait sur un ordinateur avec Ubuntu, mais pas sur d'autres avec des distributions différentes et des versions plus anciennes d'OpenSSH.
La même solution pour la machine Windows:
- Générer une clé SSH et ajouter une clé au serveur Git Lab
- Assurez-vous que 2 fichiers de clé SSH sont dans le dossier /.ssh (par exemple, C:\Users\xxx.ssh)
Le clonage doit réussir sans mot de passe requis.
J'avais la bonne clé publique/privée, mais cela semblait quand même ne pas fonctionner (j'ai les mêmes erreurs, demandant le mot de passe de git-user). Après un redémarrage de l'ordinateur, cela a bien fonctionné!
si vous êtes sûr d'avoir téléchargé le contenu de key.pub dans GitLab, procédez comme suit: 1- Ouvrez Git Bash "Not CMD" 2- Accédez au dossier de la solution "CD Path" 3- Tapez Git Init 4- Tapez Git Add . 4- Tapez Git Commit 6- Tapez Git Push
et cela fonctionnera ... un autre indice: assurez-vous que le chemin du fichier où vous avez copié la clé est correct et équivalent au même chemin que celui affiché sur CMD lors de la création des clés
En règle générale, si vous avez configuré plusieurs clés via ssh sur votre système (mon appareil exécute Windows 10), vous rencontrerez ce problème. La solution est de:
Condition: configurez vos clés SSH comme indiqué par GitLab.
- ouvrir le fichier /c/Users//.ssh/config avec Notepad ++ ou votre éditeur favori
- collez le texte suivant à l'intérieur . Hôte IdentityFile ~/.ssh/
Veuillez noter qu'il y a un espace avant la deuxième ligne, ce qui est très important pour éviter que cette solution ne fonctionne pas.
Sur ma machine Windows 10, c'était parce que la variable d'environnement SSH_GIT n'était pas configurée pour utiliser le plink PuTTY que j'avais installé sur ma machine.
Avait le même problème dans Windows 10 (ne sais pas si cela est pertinent) . Si tout était configuré correctement, la commande ssh -vT git@myserver a réussi, mais Gitlab a tout de même demandé mon mot de passe.
Supprimer puis recréer la clé dans Gitlab était pour moi un truc.
Sous Windows 10 en utilisant le terminal sous VS Code, j'ai reçu l'invite du mot de passe "git @ gitlab:" lorsque j'essayais de:
git Push -u Origin --all
J'avais établi mes informations d'identification SSH dans Windows et dans Gitlab, mais j'avais utilisé Windows 10 bash key-gen pour le faire. La solution consistait alors à appeler bash dans VS code terminal, puis à relancer la commande.
bash
git Push -u Origin --all
Ça a réussi.
Pour éviter de devoir utiliser bash/git manuellement, j'ai alors placé un lien symbolique entre les fenêtres .ssh/id_rsa et le shell bash .ssh/id_rsa:
C:\Users\bruce\.ssh>mklink id_rsa C:\Users\bruce\AppData\Local\lxss\home\bruce\.ssh\id_rsa
Les actions du menu VS Code Git (Push, Pull, etc.) fonctionnent désormais avec gitlab
Mon problème était que j'avais une entrée de DNS pour gitlab.example.com pour indiquer mon équilibreur de charge. Donc, quand j’ai essayé de ssh [email protected], j’ai vraiment été ssh sur la mauvaise machine.
J'ai fait une entrée dans mon fichier ~/.ssh/config:
Host gitlab.example.com
Hostname 192.168.1.50
Cela a perdu beaucoup de temps ...
J'ai eu le même problème, .__ J'ai passé beaucoup de temps à chercher!
J'ai eu l'idée d'utiliser Eclipse pour importer le projet depuis GitLab.
Une fois le projet importé correctement, j'ai comparé la configuration de:
- le ripository Git du projet que j'ai importé dans Eclispe, ("dans Eclipse", référentiel Git, dans myprojectRepo/Working Directory/.git/config)
- celui qui est fait dans .git/config, là je voulais pousser mon projet avec git: git Push ... et m'a demandé un mot de passe.
Surprise: la télécommande n’a pas la même chose dans les deux cas ..__ J'ai remis la même chose que celle d’Eclipse et tout fonctionne.