git push Access denied. #4730

Closed
kapoorsunny opened this Issue Aug 7, 2013 · 88 comments

Comments

Projects
None yet

Hi,

I am using gitlab 5.3 stable version, and below are the errors an getting while i push anything to the repo

git push -u origin master
Access denied.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Please HELP !!!!

Did you upload you SSH key to the server?

Yes
On 07-Aug-2013 8:31 PM, "Sean Freiburg" notifications@github.com wrote:

Did you upload you SSH key to the server?


Reply to this email directly or view it on GitHubhttps://github.com/gitlabhq/gitlabhq/issues/4730#issuecomment-22257440
.

When I do ssh git@localhost
It gives me "Welcome Gitlab" Anonymous
On 07-Aug-2013 8:34 PM, "Kapoor" kapoor@capecode.in wrote:

Yes
On 07-Aug-2013 8:31 PM, "Sean Freiburg" notifications@github.com wrote:

Did you upload you SSH key to the server?


Reply to this email directly or view it on GitHubhttps://github.com/gitlabhq/gitlabhq/issues/4730#issuecomment-22257440
.

Does your git user have permissions to write to the directory you are pushing to?

I have git user created from Gui and it is master of the repo
On 07-Aug-2013 8:54 PM, "Sean Freiburg" notifications@github.com wrote:

Does your git user have permissions to write to the directory you are
pushing to?


Reply to this email directly or view it on GitHubhttps://github.com/gitlabhq/gitlabhq/issues/4730#issuecomment-22258837
.

Does doing ssh -T git@gitserverbox
Should show user name in welcome message ?
Right now it's says welcom gitlab "anonymous"
On 07-Aug-2013 8:55 PM, "Kapoor" kapoor@capecode.in wrote:

I have git user created from Gui and it is master of the repo
On 07-Aug-2013 8:54 PM, "Sean Freiburg" notifications@github.com wrote:

Does your git user have permissions to write to the directory you are
pushing to?


Reply to this email directly or view it on GitHubhttps://github.com/gitlabhq/gitlabhq/issues/4730#issuecomment-22258837
.

You need to use your SSH key, that is the only thing that produces that error. @seanfreiburg was correct.

I am using ssh key moreover git push origin master uses the key from .ssh
folder.
There something trivial missing
On 07-Aug-2013 10:02 PM, "Jonathan Delgado" notifications@github.com
wrote:

You need to use your SSH key, that is the only thing that produces that
error. @seanfreiburg https://github.com/seanfreiburg was correct.


Reply to this email directly or view it on GitHubhttps://github.com/gitlabhq/gitlabhq/issues/4730#issuecomment-22264106
.

Are you using id_rsa.pub ?

walterra commented Aug 7, 2013

I have the same problem. Before the problem arised I had the very same key working for me.

What I did for some testing is removing the key, adding it at another user's account, trying some things out and moving the key back to the original user. I ended up with the same error message as described.

Looking at .ssh/authorized_keys, it turns out at one point the key wasn't correctly deleted and it now shows up twice with different key-ids.

Yes am using is_rsa.pub and copy past it into gui when asked for ssh key

Below are some more details:

Logs from gitlab-shell :

W, [2013-08-07T18:53:25.448121 #9898] WARN -- : gitlab-shell: Access
denied for git command <git-receive-pack 'SunnyKapoor/qwerty.git'> by user
with key key-16.

ssh says:

ssh -T git@localhost
Welcome to GitLab, Anonymous!

I have only one key on git server created.

Thanks
Abhi

On Wed, Aug 7, 2013 at 10:32 PM, Walter Rafelsberger <
notifications@github.com> wrote:

I have the same problem. Before the problem arised I had the very same key
working for me.

What I did for some testing is removing the key, adding it at another
users account, trying some things out and moving the key back to the
original user. I ended up with the same error message as described.

Looking at .ssh/authorized_keys, it turns out at one point the key wasn't
correctly deleted and it now shows up twice with different key-ids.


Reply to this email directly or view it on GitHubhttps://github.com/gitlabhq/gitlabhq/issues/4730#issuecomment-22266478
.

Thanks and Regards
Kapoor
*
*
Twitter: @kapoorsunny

I have created a user through GUI with name "sunny" and the same user has
created the project "world".
Then created ssh key using the following command on the client login

ssh-keygen -t rsa -C "abhishek.kapoor@impetus.co.in"

then I have added key generated into the ssh keys section from GUI.

Now as per the above configuration I should ssh the git box

ssh -vt git@gitlab.impetus-n096.com

Below are the verbose logs

OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to gitlab.impetus-n096.com [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/impadmin/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/impadmin/.ssh/id_rsa-cert type -1
debug1: identity file /home/impadmin/.ssh/id_dsa type -1
debug1: identity file /home/impadmin/.ssh/id_dsa-cert type -1
debug1: identity file /home/impadmin/.ssh/id_ecdsa type -1
debug1: identity file /home/impadmin/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1
Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA
16:ef:91:1e:1c:0d:44:ca:3c:c0:c7🆎1d:4e:8f:4c
debug1: Host 'gitlab.impetus-n096.com' is known and matches the ECDSA host
key.
debug1: Found key in /home/impadmin/.ssh/known_hosts:67
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/impadmin/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to gitlab.impetus-n096.com ([127.0.0.1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Sending environment.
debug1: Sending env LANG = en_IN
PTY allocation request failed on channel 0
impadmin@impetus-N096:/temp/clone9/world$ cat log
impadmin@impetus-N096:
/temp/clone9/world$ ssh -vt
git@gitlab.impetus-n096.com >> log
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to gitlab.impetus-n096.com [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/impadmin/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/impadmin/.ssh/id_rsa-cert type -1
debug1: identity file /home/impadmin/.ssh/id_dsa type -1
debug1: identity file /home/impadmin/.ssh/id_dsa-cert type -1
debug1: identity file /home/impadmin/.ssh/id_ecdsa type -1
debug1: identity file /home/impadmin/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1
Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA
16:ef:91:1e:1c:0d:44:ca:3c:c0:c7🆎1d:4e:8f:4c
debug1: Host 'gitlab.impetus-n096.com' is known and matches the ECDSA host
key.
debug1: Found key in /home/impadmin/.ssh/known_hosts:67
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/impadmin/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to gitlab.impetus-n096.com ([127.0.0.1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Sending environment.
debug1: Sending env LANG = en_IN
PTY allocation request failed on channel 0

After i did
git push -u origin master

Output:

Access denied.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Below are the ls output of the git box (repositories is changed 777
intentioanally)

git@impetus-N096:~$ ls -ltr
total 20
drwxr-xr-x 16 git git 4096 Aug 6 12:36 gitlab
drwxrwxr-x 3 git git 4096 Aug 6 13:04 temp
drwxr-xr-x 4 git git 4096 Aug 7 12:26 gitlab-satellites
drwxrwsrwx 5 git git 4096 Aug 7 18:52 repositories
drwxr-xr-x 8 git git 4096 Aug 8 12:08 gitlab-shell

Below are the logs of gitlab-shell

I, [2013-08-08T12:11:06.111166 #15054] INFO -- : Removing key key-22
I, [2013-08-08T12:11:57.115998 #15092] INFO -- : Adding key key-23 =>
"ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDCnVxgIgNHOjxYzFIxYH22jOe1EVOQHQ9Lq6slC7EVbNcxmsiHWhHCYPHmTBO0POWBslAHLBTR4gWUxpfFLNUd6rr1WfbEjwo+8tDXcvmIW1BgzvQOVL+NEEYNweEZ3WI2PRvv2QeX+QqEhnfKhlC+BUg1GUF16UKnErD9V1FoyECJQ79Jqlka/XAjK5rLaMJC8wZcT6I1fsbULJ6kwthimEhOkD7kCDOJilZg+Cbvv1mLWpdomDK3vdc+zLj3QuYOEIB+DaCSm3Ua0qRY1vnBgMQk6CzPHftisa2rEYkqcPhsJhlH9JTw8nf/+L71SqWYWCMMzrBJpBDwnhtCAHL3
abhishek.kapoor@impetus.co.in"
I, [2013-08-08T12:14:51.185698 #15332] INFO -- : Adding project
SunnyKapoor/world.git at </home/git/repositories/SunnyKapoor/world.git>.
W, [2013-08-08T12:15:27.068290 #15499] WARN -- : gitlab-shell: Access
denied for git command <git-receive-pack 'SunnyKapoor/world.git'> by user
with key key-23.
W, [2013-08-08T12:18:12.332170 #15654] WARN -- : gitlab-shell: Access
denied for git command <git-receive-pack 'SunnyKapoor/world.git'> by user
with key key-23.
W, [2013-08-08T12:23:04.954911 #16010] WARN -- : gitlab-shell: Access
denied for git command <git-receive-pack 'SunnyKapoor/world.git'> by user
with key key-23.
W, [2013-08-08T12:41:03.764366 #16291] WARN -- : gitlab-shell: Access
denied for git command <git-receive-pack 'SunnyKapoor/world.git'> by user
with key key-23.
W, [2013-08-08T12:45:29.242238 #17198] WARN -- : gitlab-shell: Access
denied for git command <git-receive-pack 'SunnyKapoor/world.git'> by user
with key key-23.

Could you please suggest if am missing something ?

Thanks
Abhi

On Thu, Aug 8, 2013 at 11:05 AM, Kapoor kapoor@capecode.in wrote:

Yes am using is_rsa.pub and copy past it into gui when asked for ssh key

Below are some more details:

Logs from gitlab-shell :

W, [2013-08-07T18:53:25.448121 #9898] WARN -- : gitlab-shell: Access
denied for git command <git-receive-pack 'SunnyKapoor/qwerty.git'> by user
with key key-16.

ssh says:

ssh -T git@localhost
Welcome to GitLab, Anonymous!

I have only one key on git server created.

Thanks
Abhi

On Wed, Aug 7, 2013 at 10:32 PM, Walter Rafelsberger <
notifications@github.com> wrote:

I have the same problem. Before the problem arised I had the very same
key working for me.

What I did for some testing is removing the key, adding it at another
users account, trying some things out and moving the key back to the
original user. I ended up with the same error message as described.

Looking at .ssh/authorized_keys, it turns out at one point the key wasn't
correctly deleted and it now shows up twice with different key-ids.


Reply to this email directly or view it on GitHubhttps://github.com/gitlabhq/gitlabhq/issues/4730#issuecomment-22266478
.

Thanks and Regards
Kapoor
*
*
Twitter: @kapoorsunny

Thanks and Regards
Kapoor
*
*
Twitter: @kapoorsunny

Just to add more

bundle exec rake gitlab:check RAILS_ENV=production

output:

Checking Environment ...

Git configured for git user? ... yes
Has python2? ... yes
python2 is supported version? ... yes

Checking Environment ... Finished

Checking GitLab Shell ...

GitLab Shell version >= 1.4.0 ? ... OK (1.7.0)
Repo base directory exists? ... yes
Repo base directory is a symlink? ... no
Repo base owned by git:git? ... yes
Repo base access is drwxrws---? ... yes
post-receive hook up-to-date? ... can't check because of previous errors
post-receive hooks in repos are links: ... can't check because of previous
errors

Checking GitLab Shell ... Finished

Checking Sidekiq ...

Running? ... yes

Checking Sidekiq ... Finished

Checking GitLab ...

Database config exists? ... yes
Database is SQLite ... no
All migrations up? ... yes
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Init script exists? ... yes
Init script up-to-date? ... yes
Projects have satellites? ...
sunny / world ... can't create, repository is empty
Redis version >= 2.0.0? ... yes
Your git bin path is "/usr/bin/git"
Git version >= 1.7.10 ? ... yes (1.8.3)

Checking GitLab ... Finished

On Thu, Aug 8, 2013 at 12:52 PM, Kapoor kapoor@capecode.in wrote:

I have created a user through GUI with name "sunny" and the same user has
created the project "world".
Then created ssh key using the following command on the client login

ssh-keygen -t rsa -C "abhishek.kapoor@impetus.co.in"

then I have added key generated into the ssh keys section from GUI.

Now as per the above configuration I should ssh the git box

ssh -vt git@gitlab.impetus-n096.com

Below are the verbose logs

OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to gitlab.impetus-n096.com [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/impadmin/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/impadmin/.ssh/id_rsa-cert type -1
debug1: identity file /home/impadmin/.ssh/id_dsa type -1
debug1: identity file /home/impadmin/.ssh/id_dsa-cert type -1
debug1: identity file /home/impadmin/.ssh/id_ecdsa type -1
debug1: identity file /home/impadmin/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1
Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA
16:ef:91:1e:1c:0d:44:ca:3c:c0:c7🆎1d:4e:8f:4c
debug1: Host 'gitlab.impetus-n096.com' is known and matches the ECDSA
host key.
debug1: Found key in /home/impadmin/.ssh/known_hosts:67
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/impadmin/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to gitlab.impetus-n096.com ([127.0.0.1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Sending environment.
debug1: Sending env LANG = en_IN
PTY allocation request failed on channel 0
impadmin@impetus-N096:/temp/clone9/world$ cat log
impadmin@impetus-N096:
/temp/clone9/world$ ssh -vt
git@gitlab.impetus-n096.com >> log
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to gitlab.impetus-n096.com [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/impadmin/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/impadmin/.ssh/id_rsa-cert type -1
debug1: identity file /home/impadmin/.ssh/id_dsa type -1
debug1: identity file /home/impadmin/.ssh/id_dsa-cert type -1
debug1: identity file /home/impadmin/.ssh/id_ecdsa type -1
debug1: identity file /home/impadmin/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1
Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA
16:ef:91:1e:1c:0d:44:ca:3c:c0:c7🆎1d:4e:8f:4c
debug1: Host 'gitlab.impetus-n096.com' is known and matches the ECDSA
host key.
debug1: Found key in /home/impadmin/.ssh/known_hosts:67
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/impadmin/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to gitlab.impetus-n096.com ([127.0.0.1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Sending environment.
debug1: Sending env LANG = en_IN
PTY allocation request failed on channel 0

After i did
git push -u origin master

Output:

Access denied.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Below are the ls output of the git box (repositories is changed 777
intentioanally)

git@impetus-N096:~$ ls -ltr
total 20
drwxr-xr-x 16 git git 4096 Aug 6 12:36 gitlab
drwxrwxr-x 3 git git 4096 Aug 6 13:04 temp
drwxr-xr-x 4 git git 4096 Aug 7 12:26 gitlab-satellites
drwxrwsrwx 5 git git 4096 Aug 7 18:52 repositories
drwxr-xr-x 8 git git 4096 Aug 8 12:08 gitlab-shell

Below are the logs of gitlab-shell

I, [2013-08-08T12:11:06.111166 #15054] INFO -- : Removing key key-22
I, [2013-08-08T12:11:57.115998 #15092] INFO -- : Adding key key-23 =>
"ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDCnVxgIgNHOjxYzFIxYH22jOe1EVOQHQ9Lq6slC7EVbNcxmsiHWhHCYPHmTBO0POWBslAHLBTR4gWUxpfFLNUd6rr1WfbEjwo+8tDXcvmIW1BgzvQOVL+NEEYNweEZ3WI2PRvv2QeX+QqEhnfKhlC+BUg1GUF16UKnErD9V1FoyECJQ79Jqlka/XAjK5rLaMJC8wZcT6I1fsbULJ6kwthimEhOkD7kCDOJilZg+Cbvv1mLWpdomDK3vdc+zLj3QuYOEIB+DaCSm3Ua0qRY1vnBgMQk6CzPHftisa2rEYkqcPhsJhlH9JTw8nf/+L71SqWYWCMMzrBJpBDwnhtCAHL3
abhishek.kapoor@impetus.co.in"
I, [2013-08-08T12:14:51.185698 #15332] INFO -- : Adding project
SunnyKapoor/world.git at </home/git/repositories/SunnyKapoor/world.git>.
W, [2013-08-08T12:15:27.068290 #15499] WARN -- : gitlab-shell: Access
denied for git command <git-receive-pack 'SunnyKapoor/world.git'> by user
with key key-23.
W, [2013-08-08T12:18:12.332170 #15654] WARN -- : gitlab-shell: Access
denied for git command <git-receive-pack 'SunnyKapoor/world.git'> by user
with key key-23.
W, [2013-08-08T12:23:04.954911 #16010] WARN -- : gitlab-shell: Access
denied for git command <git-receive-pack 'SunnyKapoor/world.git'> by user
with key key-23.
W, [2013-08-08T12:41:03.764366 #16291] WARN -- : gitlab-shell: Access
denied for git command <git-receive-pack 'SunnyKapoor/world.git'> by user
with key key-23.
W, [2013-08-08T12:45:29.242238 #17198] WARN -- : gitlab-shell: Access
denied for git command <git-receive-pack 'SunnyKapoor/world.git'> by user
with key key-23.

Could you please suggest if am missing something ?

Thanks
Abhi

On Thu, Aug 8, 2013 at 11:05 AM, Kapoor kapoor@capecode.in wrote:

Yes am using is_rsa.pub and copy past it into gui when asked for ssh key

Below are some more details:

Logs from gitlab-shell :

W, [2013-08-07T18:53:25.448121 #9898] WARN -- : gitlab-shell: Access
denied for git command <git-receive-pack 'SunnyKapoor/qwerty.git'> by user
with key key-16.

ssh says:

ssh -T git@localhost
Welcome to GitLab, Anonymous!

I have only one key on git server created.

Thanks
Abhi

On Wed, Aug 7, 2013 at 10:32 PM, Walter Rafelsberger <
notifications@github.com> wrote:

I have the same problem. Before the problem arised I had the very same
key working for me.

What I did for some testing is removing the key, adding it at another
users account, trying some things out and moving the key back to the
original user. I ended up with the same error message as described.

Looking at .ssh/authorized_keys, it turns out at one point the key
wasn't correctly deleted and it now shows up twice with different key-ids.


Reply to this email directly or view it on GitHubhttps://github.com/gitlabhq/gitlabhq/issues/4730#issuecomment-22266478
.

Thanks and Regards
Kapoor
*
*
Twitter: @kapoorsunny

Thanks and Regards
Kapoor
*
*
Twitter: @kapoorsunny

Thanks and Regards
Kapoor
*
*
Twitter: @kapoorsunny

ipsec commented Aug 8, 2013

Same problem here

Silly me, i missed port number in config.yml in gitlab-shell .....
Problem is now sorted .

Contributor

begnini commented Aug 18, 2013

I constantly have the same problem. In my case, the problem is caused by puma eating all memory availabe. Restarting gitlab always works.

To be honest
Am also facing some issue
When user adds its ssh key through web end, it does not reflect into
authorised keys of the server. So I have to restart the gitlab server get
it included.
I am not a ruby guys so don't know whether it's a puma or gitlab.
On 19-Aug-2013 12:10 AM, "Humberto Pereira" notifications@github.com
wrote:

I constantly have the same problem. In my case, the problem is caused by
puma eating all memory availabe. Restarting gitlab always works.


Reply to this email directly or view it on GitHubhttps://github.com/gitlabhq/gitlabhq/issues/4730#issuecomment-22836372
.

Ilviann commented Aug 19, 2013

Same problem.
Clean install of version 5.4 in accordance to guide on clean Debian 7.
bundle exec rake gitlab:check RAILS_ENV=production and sudo -u git -H /home/git/gitlab-shell/bin/check did not show errors.

Same problem for me with a clean install on Ubuntu 13.04. I also don't get any errors on the checks.

Ilviann commented Aug 20, 2013

Updated to 6-0-stable. Same error.

gitlab-shell/gitlab-shell.log contains lines like

W, [2013-08-20T23:37:07.094636 #3370]  WARN -- : gitlab-shell: Access denied for git command <git-upload-pack 'group/repo.git'> by user with key key-5.

I managed to fix it, but I'm not entirely sure how. I ran gitlab-shell/bin/check and noticed a problem with my gitlab_url (had to add an entry to hosts).

Then I manually cleared ssh keys sudo -u git -H bin/gitlab-keys clear, deleted from web page, rebooted and added again and it started to work!

In between all that I also manually added and removed some projects using gitlab-shell, but that didn't seem to fix it.

I'm actually having the same issue on Ubuntu 12.04, Gitlab 6-0 stable. Cloning and pushing via http seems to work fine, but SSH is jammed. I've attempted running the clear command, removing the keys and restarting the service (as opposed to rebooting) without any luck.

This is also happening to me. Ubuntu 12.04, Gitlab 6-0 stable, HTTP cloning works fine, the web site works fine, but cannot clone from ssh.

When trying to clone:

$ git clone git@myserver.com:juan.alvarez/test1.git
Cloning into 'test1'...
Access denied.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

On the server side this is happening in gitlab-shell.log:

E, [2013-08-24T20:10:52.765103 #7728] ERROR -- : API call <GET http://myserver.com//api/v3/internal/allowed?key_id=1&action=git-upload-pack&ref=_any&project=juan.alvarez/test1> failed: 404 => <{"message":"404 Not found"}>.
W, [2013-08-24T20:10:52.765312 #7728]  WARN -- : gitlab-shell: Access denied for git command <git-upload-pack 'juan.alvarez/test1.git'> by user with key key-1.

And the server /var/log/auth.log of the server said

Aug 24 20:18:59 gringa sshd[8616]: reverse mapping checking getaddrinfo for cpe-MY-IP-HERE.telecentro-reversos.com.ar [my ip here] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 24 20:18:59 gringa sshd[8616]: Accepted publickey for git from XXXXXXX port 53022 ssh2
Aug 24 20:18:59 gringa sshd[8616]: pam_unix(sshd:session): session opened for user git by (uid=0)
Aug 24 20:19:00 gringa sshd[8694]: Received disconnect from XXXXXXX: 11: disconnected by user
Aug 24 20:19:00 gringa sshd[8616]: pam_unix(sshd:session): session closed for user git
Aug 24 20:19:01 gringa CRON[8699]: pam_unix(cron:session): session opened for user www-data by (uid=0)
Aug 24 20:19:01 gringa CRON[8699]: pam_unix(cron:session): session closed for user www-data

So, it doesn't seems to be an ssh problem.

Any help is more than welcomed!

It finally worked doing as per trsaunders

sudo -u git -H bin/gitlab-keys clear

rebooted

sudo -u git -H bundle exec rake gitlab:shell:setup RAILS_ENV=production

Clone worked...

No luck after a reboot and following @trsaunders instructions. I'll keep tryin'.

bradmcl commented Sep 3, 2013

I saw this problem as well. It was an error in the gitlab_url setting in gitlab_shell/config.yml (mentioned above several times). Try cutting and pasting that URL out of the config file and into a browser. If it doesn't work, you know what you need to fix.

bikeshm commented Oct 10, 2013

hi i am using windos 7 and git shell , where can i find config.yml

"Silly me, i missed port number in config.yml in gitlab-shell .....
Problem is now sorted ."

Following the installation guide for GitLab using 6.0 stable, I got the Access denied when accessing repositories via git@ handle (http access was ok).

The fix was to replace gitlab_url: http://localhost/ with gitlab_url: http://127.0.0.1/ in gitlab-shell/config.yml.

This worked for me. I have changed the URL from "http://localhost/" to "http://127.0.0.1" (without ending slash).
I referred this link : http://stackoverflow.com/questions/18727678/gitlab-cloning-via-ssh-on-a-fresh-install-fails-with-the-remote-end-hung-up

winya commented Oct 23, 2013

Adding my FQDN to /etc/hosts as 127.0.0.1 helped me to resolve the problem.

# nano /etc/hosts

and then

127.0.0.1       localhost foo.bar.com

OK WInya, I will test this on my server.

cyle commented Oct 24, 2013

FYI -- I fixed this issue by going into /etc/nginx/sites-enabled/gitlab and changing the "listen [ip-addr]:80 default_server;" from having an IP address to just "listen *:80 default_server;"

The root of the problem was gitlab-shell doing an API call to figure out if the SSHing user has permission to the repo and nginx sending back the nginx welcome page. So a mismatch between gitlab, the /etc/hosts file, and the nginx config. All of them have to be pointing to the same IP address -- if you have 127.0.0.1 in one but the nginx conf is only listening on the server's actual IP address, it'll all fall apart. Hope that helps.

I follow all that tutorial with a clean server: https://github.com/gitlabhq/gitlabhq/blob/6-1-stable/doc/install/installation.md

System:

  • Ubuntu Server 13.10
  • Apache 2.4
  • Postgres 9.1
  • Self-signed certificates

and i have the same problem.

#git push -u origin master
Access denied.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

To fix it i search on google ... 1 week later and tons of test, i try to do that:

#sudo vi /home/git/gitlab-shell/config.yml
gitlab_url: "http://server/" => gitlab_url: "https://server/" (note, HTTP to HTTPS)
self_signed_cert: false => self_signed_cert: true (note, false to true)

#git push -u origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 207 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@server:root/test.git

  • [new branch] master -> master

Voila !!
Thanks Google, thanks to all.

I'm experiencing this same issue on 6-2-stable.

Tried @juanalvarezg's suggestion #4730 (comment) with no luck. Even tried removing my key(s) through the web interface and re-adding, still fails. My gitlab_url and self_signed_cert haven't changed and are correct. The environment and full check bundles look good. Nothing interesting in nginx logs. No conflicts regarding 127.0.0.1 vs localhost (using FQDN). Direct SSH test says welcome to GitLab. I'm out of things to check. Any other ideas?

Try @cyle fix and also this worked for me. I have changed the URL from "http://localhost/" to "http://127.0.0.1" (without ending slash).

@girishkg That didn't work for me. I use the FQDN for the gitlab URL and I tried changing the gitlab-shell config to reference the IP (no trailing slash) instead of the DNS name but the results were the same. I can see in the nginx access log that it's calling //api/v3/internal/allowed?key_id=5&action=git-receive-pack&ref=_any&project=user/test and simply returns false (therefore, access denied).

Edit: I should note that I did try changing it to 127.0.0.1 and experienced the same results.

Edit 2: Reverting to 6-1-stable resolved the issue. @randx

cyle commented Nov 5, 2013

I started having this exact issue again, after I fixed it with the above fix I mentioned. There was seemingly no cause. Restarting gitlab, nginx, mysql, the server, nothing fixed it. Turning on audit_usernames and log_level to DEBUG in gitlab-shell config showed in the gitlab-shell log that my name was getting found correctly, but permission to do anything with the repo via push/pull was simply "false". Which makes no sense because none of the permissions had changed. I tried clearing out the keys and rebuilding them to no avail.

The only way I ended up fixing it was updating to the latest version, 6.2.3, following the patch notes here: https://github.com/gitlabhq/gitlabhq/blob/master/doc/update/patch_versions.md

I just tried upgrading from 6-1-stable to v6.2.3 and it broke again with this same permission problem. Reverted back to 6-1-stable so my system would be functional.

Note: I run GitLab on two different servers, one of them is working just fine while the other is plagued by this issue.

Edit/Update: I rebuilt the server from scratch (different flavor of Linux) and tried to migrate the database backup over to the new system after upgrading the old system to v6.2.3. This issue came with it. Reverted the source system to 6-1-stable again, migrated that database backup to the new server, then upgraded to 6-2-stable (which now includes the v6.2.3 security fixes) and it seems to be working normally. So, take that for whatever it's worth.

trusktr commented Nov 7, 2013

I just had this problem. In my case, I had to go into ./gitlab-shell/config.yml and make sure gitlab_url had the appropriate url matching my server. More specifically, I'd forgotten to put https instead of http because I'm using ssl. I also had to make sure self_signed_cert had the proper value (it needed to be true since I'm using a self signed certificate).

I had this problem: From computer A both push and pull were working fine, from computer B only pull. Push gave that nasty

Access denied.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Here was my fix (how simple it looks now!):

  1. on gitlab web delete ssh keys for the user.
  2. on the gitlab server go to /home/git/.ssh/authorized_keys. Delete all entries related to the user
  3. on gitlab web add the ssh key one more time

from gitlab-shell.log you can find out which key is not working and precisely delete/add it. In my case it was a relatively new setup so I could delete a bunch.

Unfortunately, the same error message/symptoms result from a myriad of different issues. There are plenty "I got it working by doing _____" examples in these comments, but none of them seem to work for everyone because there are different root causes in play.

cyle commented Nov 13, 2013

Agreed. However, since it seems to happen somewhat often, maybe it'd help to include this in the GitLab troubleshooting guide if it isn't in there already.

Same problem here. The last comment by @trusktr helped in my case. I'd say that it's somewhat counter-intuitive to look for the URL being misconfigured, when you're faced with a problem that seems to be with SSH. Just out of curiosity: how can these things be related? Is there some protocol-independent authorization scheme that involves the URL?

cyle commented Nov 13, 2013

Here's how it works, and why it involves the URL:

  1. You do a push/pull on a repo on gitlab. This connects to gitlab via SSH using the "git" user.
  2. Gitlab-shell sees you trying to log in via ssh as the "git" user.
  3. Gitlab-shell sees what key you're using and tries to find what user is associated with that key; this is an API call that requires a URL to your gitlab installation. This is configured in the gitlab-shell config.
  4. Gitlab-shell, once it has the user associated with the key, tries to find out if that user has access to the repo you're pushing/pulling; this is an API call that requires a URL to your gitlab installation.
  5. Gitlab-shell gets one of three values from the API on that last call: true, false, or an error. In the event of an error or a false, you get an "Access Denied" for your push/pull attempt, and if you have debug logging on, gitlab-shell writes in its log the error. However, turning audit_usernames to true will show you whether it can even get the right username based on the given key in the first place.

So you can see that if gitlab-shell is configured with the wrong URL, it won't be able to make an API call to gitlab, and it won't know what to do, thus error-ing out and giving you an "Access Denied". The URL could be correct in the gitlab-shell config, but maybe your /etc/hosts file isn't mapping the URL to your IP address, and on top of that, it's possible nginx wasn't configured to listen on 127.0.0.1, but instead on your external IP address only. All of these things could be broken, or only one of them, but nevertheless they all contribute to possibly getting an "Access Denied" error.

Thanks for the explanation ;) I was not aware of the fact that gitlab-shell uses the HTTP API to communicate with GitLab. In hindsight that makes sense though.

@cyle Or something else entirely could be broken. In my case, my URL was correct, my hosts file was correct, nginx was correct, every configuration option I could possibly find to investigate was correct. On top of that, I could get it to break by simply upgrading GitLab (leaving all the other configurations I mentioned alone). Reverting to a previous version would resolve the issue. Something was getting hosed somewhere when upgrading (I suspect the database, but I can't confirm that) that caused the API call validating a user via SSH key to return 'false' when it clearly should've been 'true'. I eventually gave up, and ended up rebuilding GitLab on another system and upgrading there, which worked. I would have preferred to figure it out so I could report back here and/or contribute a fix, but I just ran out of time.

koenw commented Nov 14, 2013

Yet another possible cause for this issue...

For me the problem was in the ldap configuration in gitlab/config/gitlab.yml. I'm using ldap authentication with an anonymous bind, but bind_dn and password in the ldap section of gitlab.yml were still set to their default values (e.g. '_the_full_dn_of_the_user_you_will_bind_with'). I didn't notice this, since ldap authentication in the web interface worked fine.

However, when an API call is made to check if the user (or ssh key) is allowed, gitlab checks if the user is blocked. If it is an ldap user, it also checks to see if the ldap user still exists (in lib/api/internal.rb, in the block under get "/allowed" do). For some reason the ldap call here (correctly) returned nil (since it was using a non existing bind user).

Apparently gitlab knows multiple ways of talking to ldap...

Anyway, if you're using ldap, check your ldap configuration.

I have a same problem but strange is that for new created user and imported ssh key user cannot push. All old users can pull/push without problems. By old users I mean created on 5.x version of gitlab. I have this in log: WARN -- : gitlab-shell: Access denied for git command git-receive-pack '/gitrepos/demo.git' by UserA.

Access Denied.
Fatal: The remote end hung up unexpectedly.

Solved. Double checking the gitlab-shell config helped.
Solution: http://stackoverflow.com/a/15504051

cyle commented Nov 20, 2013

Potential cause of the problem as well: if you move the user within LDAP, as in between OUs, then they'll need to re-login to gitlab itself before they can push/pull using gitlab-shell, because it seems that gitlab-shell just looks up the DN that was stored in the database based on the last time the LDAP user logged in. I'd expect that it'd do the same thing logging in does and actually search for the user within LDAP, but it looks like it doesn't. The only time that stored DN gets updated is when a user logs into gitlab via the web interface. If they haven't, gitlab-shell will try to look up their old DN, not find the user, and throw an "Access Denied" error.

Contributor

klynch commented Nov 22, 2013

I had this issue because I had persistent control connections after doing maintenance on the server. Removing these fixed the issue immediately.

    ControlMaster auto
    ControlPath ~/.ssh/control-%r@%h:%p
    ControlPersist yes

@klynch, thanks it helped

SSH master is required to me for work. So this's very serious bug, IMHO.

Temporary solution:

Add to sshd_config on server-side:

Match User git
        MaxSessions 1
Contributor

jvanbaarsen commented Jan 15, 2014

@SaitoWu Can you maybe take a look?

Contributor

SaitoWu commented Jan 16, 2014

Seems like gitlab-shell can't recognize the url which gitlab holds.

Check the configuration in gitlab-shell, make sure gitlab-api can be called. ( include nginx configuration

Check the /home/git/.ssh/authorized_keys, make sure the op user's public key in it.

Check the gitlab process, make sure gitlab's unicorn processes are running.

Those are the check steps when i cant clone from SSH. Hope it helps.

/cc @jvanbaarsen

@SaitoWu, the problem is that "git push" doesn't work while SSH connection multiplexing. Disabling of this feature makes "git push" working. So gitlab-shell configuration, authorized_keys, gitlab processes and so on are fine.

halles commented Jan 18, 2014

[EDITED]

After a couple of minutes reading my own post here, i realized the hostname configured in the repository was incorrect. So when doing push it would connect to another server which has ssh, but when i was trying to connect through ssh i input the correct domain, so it would connect correctly. My install was working fine all along. Sorry for the interruption!

related issue #5812 (comment)

trusktr commented Feb 6, 2014

Hey all, I have this issue again but no luck solving it this time. So for now, I'll just be using the HTTP version for the remote origin. I'm hoping that turning on SSL will continue working so stuff isn't in plain text.

@trusktr You have to use HTTPS if you want an encrypted transport.

@ghost

ghost commented Feb 6, 2014

@Carles74 Thanks for your help, it's working for me ;)

trusktr commented Feb 7, 2014

I just found another thing to check for. Using /bin/false for git user's shell doesn't work, so changing it to /bin/bash fixed it. Also be sure to disable password authentication in sshd_config settings for the git user so that only authentication with SSH keys is allowed (the keys you add through the GitLab web interface)

See #6266

What worked for me (running gitlab behind Apache) was to change the gitlab_url in gitlab-shell/config.yml to "http://localhost:8080" - I'd forgotten unicorn was running on 8080.

Contributor

jvanbaarsen commented Mar 21, 2014

It's been at least 2 weeks (and a new release) since we heard from you. I'm closing this issue but if you still experience this problem, please open a new issue (but also reference the old issue(s)). Make sure to also include the necessary debugging information conforming to the issue tracker guidelines found in our contributing guidelines. /cc: @Razer6

Razer6 closed this Mar 21, 2014

@cyle, thanks. (nginx site conf points to right IP)

mar-io commented Jul 8, 2014

I was having this same issue with a new gitlab install. The weird thing was in the gitlab-shell logs I was getting a 500 server error.

I tried all the above configuration and read the omnibus cookbook until my eyes bled but nothing worked. I then just tried to delete and recreate the project. I made sure to recreate the repo as the same user I was pushing as. After I deleted and recreated with my user I was able to push.

I actually just had exact the same issue as @badmadrad and recreating the repository worked also in my case. I was also able to observe the 500 HTTP response code when I requested the URL that was printed in the gitlab-shell logs.

semirke commented Jul 19, 2014

Same here.

Got problem and solution: https.
Nginx had http->https redirection.
So I set /home/git/gitlab-shell/config.yml
gitlab_url: https://git.mydomain.hu/

However, then git push failed:
/usr/local/lib/ruby/2.0.0/net/http.rb:918:in `connect': SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (OpenSSL::SSL::SSLError)

It was because I set up nginx without the intermediate CA in the crt.
Added Intermediate CA to nginx's ssl_certificate file, and now everyone runs happily. :)

I had similar issues, however my problem was that I changed from http to https after I completed the installation.

The gitlab-shell was getting 302 error coz the webserver was forcing access from http to https. Hence the redirect caused confusion to gitlab-shell.

Changed the git host address from http to https and it worked just fine.

zeayes commented Aug 25, 2014

I had this problem, but i had soloved it.

I found it in log/sidekip.log:

/home/git/gitlab-shell/lib/gitlab_keys.rb:87:in `initialize': Permission denied - /home/git/.ssh/authorized_keys.lock (Errno::EACCES)

so, change this file's access permission to user git

chmod u+wrx /home/git/.ssh/authorized_keys.lock

I had the same issue and realised that there were 2 copies of the offending key. I tried to remove all keys from the GUI and add a new one, and that resulted in a 500 error. Then I tried to regenerate the keys and it resulted in a memory error. I believe the 500 error was due to memory as well.

root@gitlab:/var/opt/gitlab# gitlab-rake gitlab:shell:setup
rake aborted!
Errno::ENOMEM: Cannot allocate memory - whoami

Tasks: TOP => gitlab:shell:setup
(See full trace by running task with --trace)

Then I removed the offending key manually from .ssh/authorized_keys and all was good again. Once in a while my developers complain about the 500 error when adding a key. I think when someone adds a key, it tries to call the same routine and fails that's why the authorized_keys file stays stale.

I'm using a 10$ Digitalocean instance which gives me 1GB RAM, isn't that enough to run this little beast ?

If you're using https, make sure you're not using port 80. In your gitlab-shell/config.yml, the gitlab_url setting should look like this:

gitlab_url: https://domain.com:443/

coolbung commented Oct 6, 2014

I'm always using the repos over SSH, so definitely an issue with keys becoming stale. I've confirmed it with another user too.

I'm using the omnibus version, the one that Digital Ocean offers in their panel as a quick install.

In my case the GIT PUSH was failing from inside RUBYMINE 6.3 but executing the same command from the Terminal window solved the problem.

KLIM8D commented Dec 17, 2014

In my case it was a silly mistake. The path to the repository folder in gitlab-shell/config.yml was different from the one in gitlab/config/gitlab.yml. Changing the "repos_path:" to the same as in gitlab-shell and restarting the gitlab service, fixed the problem.

mickmak commented Mar 8, 2015

I worked around with this issue for a couple of hours.
I dont sure if the config of my server is misconfigured.

In my case, the problem is:
/home/git/.ssh/authorized_keys just cannot update after I added a new SSH-key in the gitlab profile page.

To quick fix:

1. Add new key to SSH-key/deploy key
2. The key has an ID
3. Edit /home/git/.ssh/authorized_keys
4. Add a new key manually, (just similar as other keys)
command="/opt/bitnami/apps/gitlab/gitlab-shell/bin/gitlab-shell key-{$KEY_ID}",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa ...
{$KEY_ID} replace with your new key ID. Copy the public key value to end of the line.

Now you should able to access the repository if you have same problem with me.
I am trying to figure out if the server has any problem...lol

coolbung commented Mar 8, 2015

A simple "gitlab-ctl reconfigure" solved the issue for me...

I'd tried reconfigure too but that used to fail due to memory.

What size server are you using ?
On Mar 24, 2015 4:02 AM, "Johannes Schneider" notifications@github.com
wrote:

A simple "gitlab-ctl reconfigure" solved the issue for me...

Reply to this email directly or view it on GitHub
#4730 (comment).

cjrk commented Jun 4, 2015

I got the same error.
Turned out that /home/git/.ssh/authorized_keys contained multiple entries for my user with the same public key, key-1 and key-5.

As far as I can see gitlab lost track of key-1, associated only key-5 to my user and i wasn't able to delete key-1 via web interface.
Possibly, when pushing changes via ssh the gitlab-shell identified me with the first entry and queried permissions for key-1, which gitlab doesn't know about.

In my case, deleting the old key-1 from /home/git/.ssh/authorized_keys solved the problem without clearing all my keys.

ssbarnea commented Aug 3, 2015

This is a gitlab bug that I just documented at https://gitlab.com/gitlab-org/gitlab-ce/issues/2156

Check your account permisions. Only owner can commit in master branch. If your account is of type Developer you need to create new branch and member who is owner will merge your branch with master branch.

Hi everyone,

Just in case it could help someone.

I've changed my router and this one does not support loopback, when I've tried to push, gitlab-shell couldn't call the API with the domain name, because of a 404 error (gitlab-shell.log was useful to discover the problem).

I've updated my /etc/hosts on my server to make 127.0.0.1 points to my domain and now it's working.

e-ruiz commented Dec 16, 2015

Be careful if you want to use special chars on your ssh-key password.
After hours without connection, I rebuild the ssh-key with "simple" password, after that, git commands (aka clone) worked fine.

To simulate do this:

$ ssh-keygen -t rsa -C"your@email"
Generating public/private rsa key pair.
Enter file in which to save the key (./id_rsa):
Enter passphrase (empty for no passphrase): p@assword
Enter same passphrase again: p@assword
Your identification has been saved in ./id_rsa.
Your public key has been saved in ./id_rsa.pub.
The key fingerprint is: bla:bla:bla

Go to GitLab and register your new ssh-key

Try to clone something via SSH:

git clone git@my-gitlab:user/project.git
Cloning into 'project'...
git@my-gitlab's password: 
Permission denied, please try again.

After regenerate a new ssh-key using a password without "@" works fine.

Actually we can use special chars on passwords, but we need to scape this chars on git commands.
Reference: http://stackoverflow.com/questions/6172719/escape-character-in-git-proxy-password

Best regards.

Nothing worked in my case. I don't know why but at last I was stuck. Finally I removed by myself. Please take a look on my answer https://gitlab.com/gitlab-com/support-forum/issues/40. I hope it may help some one.

Go to your settings ssh and gpg keys remove all the ssh keys
open up terminal type cd ~/.ssh
then type ssh-keygen -t rsa -C 'example@gmail.com'
take a file name to save for example git_filessh
skip password pressing enter
type cat git_filessh /or any name you give to save it
copy the ssh-key
go to settings and ssh gpg then add new ssh type a name and pate the ssh from terminal /cmd
then type ssh-add before that type
eval ssh-agent -s /if you r using later version of git
type ssh-add
finally type ssh -T git@github.com
git will allow your shell access now u can push and fix repositiry

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment