Obtention de l'autorisation refusée (clé publique) sur gitlab

Mon problème est que je ne peux pas pousser ou récupérer depuis GitLab. Cependant, je peux cloner (via HTTP ou via SSH). J'obtiens cette erreur lorsque j'essaye de pousser:

Autorisation refusée (publickey) fatale: impossible de lire à partir du référentiel distant

De tous les fils que j'ai regardés, voici ce que j'ai fait:

• Configurer une clé SSH sur mon ordinateur et ajouter la clé publique à GitLab
• Terminé la configuration - global pour le nom d'utilisateur et l'email
• Cloné via SSH et via HTTP pour vérifier si cela résoudrait le problème
• Terminé la commande ssh -T git@gitlab.com

Si vous avez des idées sur la façon de résoudre mon problème, nous serions très reconnaissants.

J'ai trouvé ça après avoir beaucoup cherché. Cela fonctionnera parfaitement bien pour moi.

1. Allez dans "Git Bash" comme cmd. Faites un clic droit et "Exécuter en tant qu'administrateur".
2. Type ssh-keygen
3. Appuyez sur Entrée.
4. Il vous demandera de sauvegarder la clé dans le répertoire spécifique.
5. Appuyez sur Entrée. Il vous demandera de taper le mot de passe ou d'entrer sans mot de passe.
6. La clé publique sera créée dans le répertoire spécifique.
7. Allez maintenant dans le répertoire et ouvrez .ssh dossier.
8. Vous verrez un fichier id_rsa.pub . Ouvrez-le sur le bloc-notes. Copiez tout le texte de celui-ci.
9. Accédez à https://gitlab.com/profile/keys .
10. Collez ici dans le champ de texte "clé".
11. Cliquez maintenant sur le "Titre" ci-dessous. Il sera automatiquement rempli.
12. Cliquez ensuite sur "Ajouter une clé".

Maintenant, essayez et cela fonctionnera à coup sûr.

Étape 1: Ajout d'un fichier de configuration dans le ~/.ssh/configfichier qui ressemble à

   User git
   Hostname gitlab.com
   IdentityFile ~/.ssh/id_rsa_gitlab
   TCPKeepAlive yes
   IdentitiesOnly yes

Étape 2: Clonez simplement le référentiel git SANS sudo.
Documentation: https://gitlab.com/help/ssh/README#working-with-non-default-ssh-key-pair-paths

Je pense que la solution simple est d'ajouter une clé privée à l'agent d'authentification (si votre clé ne l'est pas ~/.ssh/id_rsa),

ssh-add ~/.ssh/<your private key>

En gros, vous laissez le ssh-agent occuper.

De plus, vous pouvez l' ajouter de manière permanente .

Dans mon cas, cela ne fonctionnait pas dans le WSL (sous-système Windows pour Linux).

Quand je lance le WSL, je dois

• démarrer ssh-agent_ eval $(ssh-agent -s)
• ajoutez la clé au ssh-agent: ssh-add ~/.ssh/id_rsa
• si vous y êtes invité, entrez le mot de passe

Maintenant, la connexion fonctionne.
Nous pouvons tester cela avecssh -T git@github.com

Remarques:

• weasel-pageant nous permet de réutiliser les clés ssh chargées dans PuTTY pageant à l'intérieur du WSL
• explication détaillée: Git via SSH à partir de Windows renvoie l'autorisation refusée

assurez-vous que vous n'êtes pas en cours d'exécution sudo git clone git@gitlab.com:project/somethiing.git, sinon ssh cherchera à la /root/.sshplace de la clé que vous avez téléchargée~/.ssh/id_rsa

Il existe une solution très simple à cela: au lieu de travailler avec ssh, passez à https. pour ce faire: dans votre dossier de projet, vous avez un dossier .git - vous avez un fichier de configuration - ouvrez-le dans un éditeur de texte et changez la ligne

url =git@gitlab.com: votre nom / votre projet.git

à

url = https://gitlab.com/yourname/yourproject.git

si vous êtes sous Linux ou macox, essayez simplement ceci dans le terminal:

ssh-add -l

s'il ne renvoie rien, essayez ceci:

ssh-add

il doit créer une identité dans ~ / .ssh / id_rsa

après une nouvelle tentative:

ssh-add -l

il doit renvoyer votre identité, donc après une nouvelle tentative de clonage, cela doit fonctionner

NB: n'oubliez pas d'ajouter votre clé ssh dans votre profil gitlab

Merci

Dans mon cas, ce n'était pas un problème gitlab, mais un problème de configuration sshd. Le serveur ssh n'autorisait pas la connexion à l'exception d'une liste d'utilisateurs. L'utilisateur git, celui qui se connecte à distance à gitlab, ne figurait pas dans cette liste. Alors, vérifiez ceci avant toute autre chose.

Vous pouvez vérifier la configuration de votre serveur ssh dans /etc/ssh/sshd_config. Si vous avez une ligne avec l'option AllowUsers, ajoutez-y git:

AllowUsers user1 user2 user3 git

J'ai gitlab en cours d'exécution avec docker, c'est ce que j'ai fait pour résoudre mon problème.

J'ai trouvé que dans docker / var / log / gitlab / sshd / current, il y avait plusieurs occurrences d'un message:

Authentification refusée: mauvaise propriété ou modes pour le fichier /var/opt/gitlab/.ssh/authorized_keys

Après quoi, j'ai changé la propriété de ce fichier de 99: users à git: users avec:

chown git: utilisateurs authorised_keys

Étapes à suivre, j'ai eu la même erreur mais je l'ai corrigée. Gitlab veut ssh-rsa donc voici le code pour exécuter ssh pour rsa

1. ssh-keygen -o -t rsa -b 4096 -C "name@gmail.com"

name@gmail.com est l'adresse e-mail de votre compte gitlab

2. Il vous demandera d'entrer, appuyez simplement sur Entrée après que le code ci-dessous soit invité,

   Entrez le fichier dans lequel enregistrer la clé (/home/yourDesktopName/.ssh/id_rsa):

3. Il vous invitera à nouveau à entrer, appuyez simplement sur Entrée après que le code ci-dessous soit invité,

   Entrez la phrase de passe (vide pour aucune phrase de passe):

4. Il vous demandera à nouveau le dernier que vous avez entré, il vous suffit d'appuyer sur Entrée après l'invite du code ci-dessous,

   Saisissez à nouveau la même phrase secrète:

5. Vous montrerez votre ssh-rsa generate.

6. Connectez-vous à votre compte Gitlab et allez dans la barre de navigation de droite, vous obtiendrez le réglage et dans la barre latérale gauche, vous obtiendrez la clé ssh. Entrez-y.

7. Regardez au-dessus de l'invite vous demandant d'entrer, vous obtiendrez le chemin de ssh-rsa.

8. Accédez à votre dossier SSH et récupérez le id_rsa.pub

9. Ouvrez-le et récupérez la clé et copiez la pâte sur le Gitlab et vous avez presque terminé.

10. Vérifier par: ssh -T git@gitlab.com

11. Tu auras: Welcome to GitLab, @joy4!

12. Terminé.

Auparavant, c'était très difficile pour moi, mais quand j'ai essayé, il est devenu si facile d'ajouter une clé ssh sous Mac et Linux. Il y a quelques étapes et commandes pour le faire comme suit:

1. Ouvrez un terminal de votre système et déplacez-vous dans le répertoire de votre projet par la commande:

cd 'project directory name'

2. Exécutez la commande ssh-keygendans ce terminal et entrez-la jusqu'à ce que l'image aléatoire de la clé y apparaisse.

3. Entrez ensuite une autre commande dans ce terminal:

cat ~/.ssh/id_rsa.pub

Il générera votre clé ssh. La clé commencera parssh-rsa et se terminera par .local.

4. Copiez la clé et accédez à la section de votre profil Gitlab, puis à la ssh keysection et collez-la là. Cliquez sur le Addbouton cela fonctionnera.

J'ai eu le même problème, je l'ai résolu en ajoutant une nouvelle clé ssh:

1. ssh-keygen -t ed25519 -C "email@example.com"
2. Copiez votre clé SSH publique dans le presse-papiers (xclip -sel clip < ~/.ssh/id_ed25519.pub dans mon cas sous Linux)
3. Sur gitlab, accédez aux settings=>sshclés et passez la nouvelle clé

Lorsque vous avez plusieurs comptes git et que vous voulez une clé ssh différente

Vous devez suivre la même étape pour générer la clé ssh, mais assurez-vous

ssh-keygen -t ed25519 -C "your-email-id@gmail.com" 

Entrez le chemin que vous souhaitez enregistrer (Ex: my-pc / Desktop / .ssh / ed25519)

Ajoutez la clé publique à votre gitlab ( Comment ajouter une clé ssh à gitlab )

Vous devez créer une nouvelle identité ssh en utilisant la commande ci-dessous

ssh-add ~/my-pc/Desktop/.ssh/ed25519

Deux choses principalement

1. Vous devez avoir les clés id_rsa.pub et id_rsa (privées) dans votre dossier .ssh (qui devrait être dans votre dossier personnel, créez-le si ce n'est pas là, mettez vos clés). Cela ne fonctionnerait pas si vous avez nommé vos fichiers clés différemment

2. Changez l'autorisation de l'id_rsa en chmod 400 ~ / .ssh / id_rsa

Un autre problème qui peut provoquer ce comportement est lorsque vous avez une configuration avec 2 emplacements% HOME% possibles.

J'utilise un PC sur lequel certains de mes documents sont stockés localement, et certains d'entre eux sont stockés sur un lecteur réseau. Certaines applications pensent que C:\Users\<MyUserName>\c'est la mienne %home%, d'autres pensent queU:\ c'est la maison.

Il s'avère que ssh-keygenj'ai mis ma clé privée sous C:\users\<MyUserName>\, et que ssh -Tetssh -v aussi regarder là - bas.

Donc, tout semble bien fonctionner, sauf cela git clone, git pushet d'autres recherchent une clé U:\. Ce qui échoue, donc j'obtiens l'erreur susmentionnée.

Il m'a fallu une heure pour le savoir, mais au final, la solution était simple: j'ai tout copié de C:\Users\<MyUserName>\.sshàU:\.ssh

J'ai résolu comme ça ...

Généré une clé pour Windows à l'aide de cette commande:

ssh-keygen -t rsa -C "your.email@example.com" -b 4096

mais le problème était qu'après l'exécution de cette commande, une ligne apparaissait: "Entrez le fichier dans lequel enregistrer la clé (/c/Users/xxx/.ssh/id_rsa):" Ici, je ne donnais que le nom de fichier à cause duquel ma clé était enregistrée dans mon pwd et non à l'emplacement indiqué. Quand j'ai fait "git clone", il supposait que la clé se trouvait à l'emplacement "/c/Users/xxx/.ssh/id_rsa" mais elle n'a pas été trouvée, d'où une erreur.

Au moment de la génération de la clé, 2 fichiers ont été générés, à savoir "file1" et "file1.pub". J'ai renommé ces deux fichiers comme

file1 -> id_rsa 

et

file1.pub -> id_rsa.pub

et placé à la fois dans l'emplacement "/c/Users/xxx/.ssh/"

Accédez au terminal et régénérez à nouveau la clé ssh. Type ssh-keygen . Il vous demandera où vous souhaitez l'enregistrer, tapez le chemin.

Copiez ensuite la clé publique sur la plateforme gitlabs. Cela commence généralement par ssh-rsa.

Le problème pour moi était que je suis passé UsePAMde yesà nodans le fichier de configuration SSH sous /etc/ssh/sshd_config. Avec UsePAM yestout fonctionne parfaitement.

J'ai trouvé la solution dans l' aide de gitlab .

To create a new SSH key pair: 
 1. Open a terminal on Linux or macOS, or Git Bash / WSL on Windows.
 2. Generate a new ED25519 SSH key pair: ssh-keygen -t ed25519 -C "email@example.com"
 2.1 Or, if you want to use RSA: ssh-keygen -o -t rsa -b 4096 -C "email@example.com"
 3. Next, you will be prompted to input a file path to save your SSH key pair to... use the suggested path by pressing Enter
 4. Once the path is decided, you will be prompted to input a password to secure your new SSH key pair. It's a best practice to use a password, but it's not required and you can skip creating it by pressing Enter twice.
 5. Copy your public SSH key to the clipboard by using one of the commands below depending on your Operating System:
        macOS:        pbcopy < ~/.ssh/id_ed25519.pub
        WSL / GNU/Linux (requires the xclip package):      xclip -sel clip < ~/.ssh/id_ed25519.pub
        Git Bash on Windows:      cat ~/.ssh/id_ed25519.pub | clip
 6. Navigating to SSH Keys and pasting your public key in the Key field
 7. Click the Add key button

J'espère que cela pourra aider certains d'entre vous!

Comment ajouter une clé SSH au compte gitlab dans ubuntu?

1. Ouvrez le terminal dans votre répertoire de projet.
2. Tapez 'ssh-keygen -o -t rsa -b 4096 -C "votre email gitlab"' et appuyez sur Entrée
3. Tapez 'vim /home/mnbtech/.ssh/id_rsa.pub' et appuyez sur Entrée (ou ouvrez manuellement votre 'id_rsa.pub' à partir de l'endroit où vous l'avez enregistré)

4. La clé SSH apparaîtra. Copiez-les et

5. Accédez à votre compte gitlab.

6. Cliquez sur l'image de profil et cliquez sur le paramètre
7. Dans le côté gauche, sélectionnez SSH-Keys
8. Puis collez ces clés Cliquez sur Ajouter une clé

La clé SSH sera ajoutée!

(NB si vous avez une clé SSH Générer des aperçus et obtenir l'autorisation refusée (clé publique). Vous supprimez votre clé ssh d'aperçus et en générez une nouvelle et ajoutez git user.name et email sur votre terminal)

J'ai résolu le git@gitlab.com: Permission denied (publickey)problème en utilisant les instructions suivantes

1. COURIR cat ~/.ssh/id_rsa.pub
2. Copiez id_rsa.pub(clé publique) dans votre getlab `Setting -> SSH Keys
3. COURIR cat ~/.ssh/id_rsa
4. Copiez id_rsa(clé privée) dans `Code_repo-> git_auth-> id_rsa

REMARQUE: prenez soin de l'utilisateur de la machine si vous utilisez rootuser dans votre DockerFile ou ailleurs, puis utilisez-le sudo suavant d'exécuter les commandes ci-dessus pour obtenir les clés publiques et privées de l'utilisateur root.

Dans notre cas, ce n'était pas un problème côté utilisateur / client, mais côté serveur Gitlab.

Nous exécutons une instance locale de Gitlab CE 12.9 sur CentOS 7.1.

Nous avons découvert que sur le serveur, le fichier .ssh / allowed_keys ne se mettait pas à jour correctement. Les utilisateurs créent leurs clés SSH (en suivant le guide Gitlab) et les ajoutent au serveur Gitlab, mais le serveur ne met pas à jour les authorised_keys , il en résultera toujours des erreurs d'autorisation refusées.

Une solution de contournement consistait à reconstruire le fichier authorized_keys en exécutant:

$ sudo gitlab-rake gitlab:shell:setup

Cela fonctionnerait pour tous ceux qui ont ajouté leurs clés avant exécuter la tâche de râteau. Pour les utilisateurs suivants qui ajouteraient leurs clés, quelqu'un doit à nouveau exécuter manuellement les tâches de rake.

Une solution plus permanente était de ne pas utiliser le authorized_keys fichier et utiliser à la place une recherche indexée sur la base de données gitlab ce :

GitLab Shell fournit un moyen d'autoriser les utilisateurs SSH via une recherche rapide et indexée dans la base de données GitLab. GitLab Shell utilise l'empreinte digitale de la clé SSH pour vérifier si l'utilisateur est autorisé à accéder à GitLab.

Ajoutez ce qui suit à votre sshd_configfichier. Il se trouve généralement à /etc/ssh/sshd_config, mais ce sera le /assets/sshd_configcas si vous utilisez Omnibus Docker:

Match User git    # Apply the AuthorizedKeysCommands to the git user only   
  AuthorizedKeysCommand /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-authorized-keys-check git %u %k   
  AuthorizedKeysCommandUser git 
Match all    # End match, settings apply to all users again 

Recharger OpenSSH:

# Debian or Ubuntu installations   
sudo service ssh reload

# CentOS installations   
sudo service sshd reload 

Confirmez que SSH fonctionne en supprimant la clé SSH de votre utilisateur dans l'interface utilisateur, en en ajoutant une nouvelle et en essayant d'extraire un dépôt.

Par défaut (enfin la valeur par défaut sur notre installation), le fichier Write to allowed_keys a été vérifié dans la zone d'administration> Paramètres d' optimisation des performances . Nous avons donc décoché cela et utilisé la base de données Gitlab à la place.

Après avoir configuré la recherche indexée et décoché le fichier Write to allowed_keys , l'accès SSH est devenu OK.

Pour toute personne utilisant Windows 10 et rien d'autre ne fonctionnant pour lui / elle:

Dans mon cas, j'ai dû cloner le repo avec https au lieu de ssh et une fenêtre s'est ouverte demandant mes informations d'identification. Après cela, tout fonctionne bien.

Je sais, je réponds très tard et même StackOverflow a confirmé si je voulais vraiment répondre. Je réponds parce que personne n'a vraiment décrit le problème réel et voulait donc partager le même.

Les bases

Tout d'abord, comprenez que c'est la télécommande ici. Remote est GitLab et votre système est le local, donc lorsque nous parlons de la télécommande origin, quelle que soit l'URL définie dans votre git remote -vsortie, c'est votre URL distante.

Les protocoles

Fondamentalement, Git clone / push / pull fonctionne principalement sur deux protocoles différents (il y en a d'autres également) -

1. Protocole HTTP
2. Protocole SSH

Lorsque vous clonez un dépôt (ou modifiez l'URL distante) et utilisez l'URL HTTP comme https://gitlab.com/wizpanda/backend-app.git il utilise le premier protocole, à savoir le protocole HTTP.

Alors que si vous clonez le dépôt (ou modifiez l'URL distante) et utilisez l'URL comme git@gitlab.com:wizpanda/backend-app.git il utilise le protocole SSH.

Protocole HTTP

Dans ce protocole, chaque opération à distance, c'est-à-dire cloner, pousser et tirer, utilise l'authentification simple, c'est-à-dire le nom d'utilisateur et le mot de passe de votre télécommande (GitLab dans ce cas), ce qui signifie que pour chaque opération, vous devez saisir votre nom d'utilisateur et votre mot de passe, ce qui peut être fastidieux. .

Ainsi, lorsque vous appuyez / tirez / clonez, GitLab / GitHub vous authentifie avec votre nom d'utilisateur et votre mot de passe et vous permet de faire l'opération.

Si vous souhaitez essayer ceci, vous pouvez passer à l'URL HTTP en exécutant la commande git remote set-url origin <http-git-url>.

Pour éviter ce cas, vous pouvez utiliser le protocole SSH.

Protocole SSH

Une simple connexion SSH fonctionne sur des paires de clés publiques-privées. Donc, dans votre cas, GitLab ne peut pas vous authentifier car vous utilisez l'URL SSH pour communiquer. Maintenant, GitLab doit vous connaître d'une manière ou d'une autre. Pour cela, vous devez créer une paire de clés publique-privée et donner la clé publique à GitLab.

Désormais, lorsque vous poussez / tirez / clonez avec GitLab, GIT (SSH en interne) proposera par défaut votre clé privée à GitLab et confirmera votre identité, puis GitLab vous permettra d'effectuer l'opération.

Je ne répéterai donc pas les étapes déjà données par Muhammad, je les répéterai théoriquement.

1. Générer une paire de clés `ssh-keygen -t rsa -b 2048 -C" Ma clé SSH commune "
2. La paire de clés générée sera par défaut ~/.sshnommée id_rsa.pub(clé publique) & id_rsa(clé privée).
3. Vous stockerez la clé publique dans votre compte GitLab (la même clé peut être utilisée dans plusieurs ou n'importe quel serveur / comptes).
4. Lorsque vous clonez / poussez / tirez, GIT propose votre clé privée.
5. GitLab fait correspondre la clé privée avec votre clé publique et vous permet d'effectuer.

Conseils

Vous devez toujours créer une clé rsa forte d'au moins 2048 octets. Donc, la commande peut être ssh-keygen -t rsa -b 2048.

https://gitlab.com/help/ssh/README#generating-a-new-ssh-key-pair

Pensée générale

Les deux approches ont leurs avantages et leurs inconvénients. Après avoir tapé le texte ci-dessus, je suis allé chercher plus à ce sujet parce que je n'ai jamais lu quelque chose à ce sujet.

J'ai trouvé ce document officiel https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols qui en dit plus à ce sujet. Ce que je veux dire ici, c'est qu'en lisant l'erreur et en réfléchissant à l'erreur, vous pouvez faire votre propre théorie ou compréhension, puis correspondre à certains résultats de Google pour résoudre le problème :)

J'ai ajouté mon ~/.ssh/id_rsa.pubà la liste des clés SSH connues dans mes paramètres GitLab https://gitlab.com/profile/keys . Cela a résolu le problème pour moi. :-)

J'utilise ubuntu 18.04, et c'était en fait un problème de permission sur ma machine locale. Le problème a disparu lorsque j'ai défini l'autorisation de lecture / écriture sur mon dossier .git.

Eh bien, j'ai eu ce même problème et après avoir essayé la réponse proposée par @Khan. Cependant, je n'ai pu le faire fonctionner qu'en changeant simplement l'URL d'origine dans le fichier .git / config à l'adresse https: https://gitlab.com/mygitlabusername/mygitproject.git

Comme l'accès via ssh est refusé, j'ai compris que l'utilisation de https ne devrait pas être un problème. Il vous demandera cependant votre nom d'utilisateur et votre mot de passe pour chaque push vers le référentiel at

Veuillez utiliser git config credential.helper storesi votre site utilise TLS / SSL. J'espère que cela fonctionne

Il semble y avoir des différences entre les deux façons d'accéder à un référentiel git, c'est-à-dire en utilisant SSH ou HTTPS. Pour moi, j'ai rencontré l'erreur parce que j'essayais de pousser mon référentiel local en utilisant SSH.

Le problème peut simplement être résolu en cliquant sur le bouton cloner sur la landing page de votre projet et en copiant le lien HTTPS et en le remplaçant par le lien SSH apparaissant au format "git @ gitlab ...".

Modifier l'autorisation :: chmod 400 ~ / .ssh / id_rsa Cela m'a aidé.