Getting permission denied (public key) on gitlab

Question

My problem is that I can\'t push or fetch from GitLab. However, I can clone (via HTTP or via SSH). I get this error when I try to push :

Permission de

Answer 1

Earlier it was very difficult for me but when I tried it became so easy to add ssh key in Mac and Linux. There are a few steps and command to do this as follows:

1. Open a terminal of your system and move inside your project directory by the command:

cd 'project directory name'

2. Run command ssh-keygen in that terminal and enter it until the key's randomart image appears there.

3. Then enter one more command in that terminal:

cat ~/.ssh/id_rsa.pub

It will generate your ssh key. Key will start with ssh-rsa and end with .local.

4. Copy the key and go to your Gitlab profile section then ssh key section and paste it there. Click on the Add button this will work.

Answer 2

I know, I'm answering this very late and even StackOverflow confirmed if I really want to answer. I'm answering because no one actually described the actual problem so wanted to share the same.

The Basics

First, understand that what is the remote here. Remote is GitLab and your system is the local so when we talk about the remote origin, whatever URL is set in your git remote -v output is your remote URL.

The Protocols

Basically, Git clone/push/pull works on two different protocols majorly (there are others as well)-

1. HTTP protocol
2. SSH protocol

When you clone a repo (or change the remote URL) and use the HTTPs URL like https://gitlab.com/wizpanda/backend-app.git then it uses the first protocol i.e. HTTP protocol.

While if you clone the repo (or change the remote URL) and uses the URL like git@gitlab.com:wizpanda/backend-app.git then it uses the SSH protocol.

HTTP Protocol

In this protocol, every remote operation i.e. clone, push & pull uses the simple authentication i.e. username & password of your remote (GitLab in this case) that means for every operation, you have to type-in your username & password which might be cumbersome.

So when you push/pull/clone, GitLab/GitHub authenticate you with your username & password and it allows you to do the operation.

If you want to try this, you can switch to HTTP URL by running the command git remote set-url origin <http-git-url>.

To avoid that case, you can use the SSH protocol.

SSH Protocol

A simple SSH connection works on public-private key pairs. So in your case, GitLab can't authenticate you because you are using SSH URL to communicate. Now, GitLab must know you in some way. For that, you have to create a public-private key-pair and give the public key to GitLab.

Now when you push/pull/clone with GitLab, GIT (SSH internally) will by default offer your private key to GitLab and confirms your identity and then GitLab will allow you to perform the operation.

So I won't repeat the steps which are already given by Muhammad, I'll repeat them theoretically.

1. Generate a key pair `ssh-keygen -t rsa -b 2048 -C "My Common SSH Key"
2. The generated key pair will be by default in ~/.ssh named id_rsa.pub (public key) & id_rsa (private key).
3. You will store the public key to your GitLab account (the same key can be used in multiple or any server/accounts).
4. When you clone/push/pull, GIT offers your private key.
5. GitLab matches the private key with your public key and allows you to perform.

Tips

You should always create a strong rsa key with at least 2048 bytes. So the command can be ssh-keygen -t rsa -b 2048.

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

General thought

Both the approach have their pros & cons. After I typed the above text, I went to search more about this because I never read something about this.

I found this official doc https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols which tells more about this. My point here is that, by reading the error and giving a thought on the error, you can make your own theory or understanding and then can match with some Google results to fix the issue :)

Answer 3

I think the simple solution is to add private key to authentication agent (if your key is not ~/.ssh/id_rsa),

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

You basically let the ssh-agent take care of it.

Additionally, you can add it permanently.

Answer 4

In our case, it wasn't a problem on the user/client side, but on the Gitlab server side.

We are running a local Gitlab CE 12.9 instance on CentOS 7.1.

We found out that on the server, the .ssh/authorized_keys file was not updating properly. Users create their SSH keys (following the Gitlab guide) and add it to the Gitlab server, but the server does not update the authorized_keys, so it will always result to permission denied errors.

A workaround was to rebuild the authorized_keys file by running:

$ sudo gitlab-rake gitlab:shell:setup

That would work for anyone who added their keys before running the rake task. For the next users who would add their keys, someone has to manually run the rake tasks again.

A more permanent solution was to not use the authorized_keys file and use instead an indexed lookup on the Gitlab database:

GitLab Shell provides a way to authorize SSH users via a fast, indexed lookup to the GitLab database. GitLab Shell uses the fingerprint of the SSH key to check whether the user is authorized to access GitLab.

Add the following to your sshd_config file. This is usually located at /etc/ssh/sshd_config, but it will be /assets/sshd_config if you're using 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 

Reload OpenSSH:

# Debian or Ubuntu installations   
sudo service ssh reload

# CentOS installations   
sudo service sshd reload 

Confirm that SSH is working by removing your user's SSH key in the UI, adding a new one, and attempting to pull a repo.

By default (well the default on our installation), the Write to authorized_keys file was checked in the Admin Area > Performance Optimization settings. So we unchecked that and used the Gitlab database instead.

After setting up indexed lookup and unchecking the Write to authorized_keys file, SSH access became OK.

Answer 5

I had the same issue, I resolved it by adding a new ssh key:

1. ssh-keygen -t ed25519 -C "email@example.com"
2. Copy your public SSH key to the clipboard (xclip -sel clip < ~/.ssh/id_ed25519.pub in my case on Linux )
3. On gitlab, go to settings=>ssh keys and past the new key

Answer 6

if you are in Linux or macox , just try this in terminal:

ssh-add -l

if it return nothing, try this:

ssh-add

it must create identity in ~/.ssh/id_rsa

after retry :

ssh-add -l

it must return your identity, so after retry to clone, it's must work

NB: don't forget to add your ssh key in your profile gitlab

thanks