I’ve been digging around for answers to this problem, and haven’t found any that address it.
This morning, I upgraded gitlab-ce omnibus edition (RHEL 7) from 12.8.8 to 12.9.2, and ssh operations (clone, push, etc) have stopped working. This is what I see when I try to clone an existing project that I own:
> git clone git@git.somewhere.com:wallis/test-project.git
Cloning into 'test-project'...
X11 forwarding request failed on channel 0
remote:
remote:
========================================================================
remote:
remote: The project you were looking for could not be found.
remote:
remote:
========================================================================
remote:
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
>
My key appears to still be ok otherwise:
> ssh git@git.somehere.com
X11 forwarding request failed on channel 0
PTY allocation request failed on channel 0
Welcome to GitLab, @dbwallis!
Connection to git.somewhere.com closed.
>
Any ideas on where to look? I’m not seeing anything in the logs, but I’ll admit to not being sure which logs to look in. git-shell.log seemed like the obvious place to start, but its empty.
After a little more digging, it seems to only be a problem for private projects… all operations seem to work fine if I change the project visibility to either public or internal.
Hi,
the SSH key points to the user dbwallis
- are you sure that it got permissions to view the project? Either direct or via group role.
Cheers,
Michael
Hi Michael,
Good catch! I’m not sure what happened, since this all worked before the update. Since I’m the admin for the gitlab instance, as well as a user, I have accounts set up with several email addresses for testing. I set up a new ssh identity/key for my primary user account, and that’s working now. I’m still not sure where the other key gets tangled up in this though.
Thanks!
Hi,
since you are saying test accounts - maybe you have been using these SSH keys for multiple users, and the one with the “first” matching profile is now used. Try to rule out that behaviour when digging deeper.
Cheers,
Michael
Hi Michael,
As far as I can figure out, I had keys on multiple accounts (my “real” account plus some test accounts), and after the update, gitlab was finding one of the test accounts instead of my “real” account. I removed the unneeded keys, and I think it’s all squared away now. I haven’t heard complaints from any other users of similar behavior, so I think it was just me.
1 Like