Removing a project with private deploy keys makes them unusable
Summary
Removing a project with a private deploy key results in an unusable SSH Keypair that cannot be used anymore.
Steps to reproduce
- Create a new project "test1"
- Generate a new deploy key on your server
- Add your deploy key (public key) to project "test1"
- Verify that access works by cloning the project "test1"
- Delete project "test1"
- Create new project "test2"
- Add your deploy key (public key) from 3. to the new project "test2"
- Try to clone project "test2" on the server:
$ git clone git@git.xyz.org:test/test-2.git
Klone nach 'test-2' ...
GitLab: The project you were looking for could not be found.
fatal: Konnte nicht vom Remote-Repository lesen.
Bitte stellen Sie sicher, dass die korrekten Zugriffsberechtigungen bestehen
und das Repository existiert.
This translates (roughly) to
$ git clone git@git.xyz.org:test/test-2.git
Cloning into 'test-2' ...
GitLab: The project you were looking for could not be found.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Additional steps done without success:
- ssh git@git.xyz.org WORKS
- auth.log says "Authentication succeded (publickey)"
- Reconfiguring gitlab via
gitlab-ctl reconfigure
- Restarting gitlab via
gitlab-ctl restart
- Restarting the machine gitlab is on
- Manually moving all sidekiq background jobs from "waiting" to "in queue"
- Using the same keypair on another computer
Example Project
See above.
What is the current bug behavior?
You cant clone project "test2" or any other project with your SSH Keypair. Neither removing them completely nor adding them as profile SSH keys works.
What is the expected correct behavior?
Cloning project "test2", permitting pushes, fetches, ...
Relevant logs and/or screenshots
None found.
Results of GitLab environment info
This happened on a private gitlab instance (installed via your Debian package) with both of these versions: 11.9.4 & 11.9.6 .
# gitlab-rake gitlab:env:info
System information
System: Debian 9.8
Current User: git
Using RVM: no
Ruby Version: 2.5.3p105
Gem Version: 2.7.6
Bundler Version:1.16.6
Rake Version: 12.3.2
Redis Version: 3.2.12
Git Version: 2.18.1
Sidekiq Version:5.2.5
Go Version: unknown
GitLab information
Version: 11.9.6
Revision: 14bac95
Directory: /opt/gitlab/embedded/service/gitlab-rails
DB Adapter: postgresql
URL: https://git.xyz.org
HTTP Clone URL: https://git.xyz.org/some-group/some-project.git
SSH Clone URL: git@git.xyz.org:some-group/some-project.git
Using LDAP: yes
Using Omniauth: yes
Omniauth Providers:
GitLab Shell
Version: 8.7.1
Repository storage paths:
- default: /var/opt/gitlab/git-data/repositories
GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell
Git: /opt/gitlab/embedded/bin/git
Results of GitLab application Check
# gitlab-rake gitlab:check SANITIZE=true
Checking GitLab subtasks ...
Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 8.7.1 ? ... OK (8.7.1)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK
Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Gitaly ...
Gitaly: ... default ... OK
Checking Gitaly ... Finished
Checking Sidekiq ...
Sidekiq: ... Running? ... yes
Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking Incoming Email ...
Incoming Email: ... Reply by email is disabled in config/gitlab.yml
Checking Incoming Email ... Finished
Checking LDAP ...
LDAP: ... Server: ldapmain
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
<SNIP>
Checking LDAP ... Finished
Checking GitLab App ...
Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
4/3 ... yes
5/5 ... yes
4/7 ... yes
5/9 ... yes
13/12 ... yes
5/13 ... yes
4/14 ... yes
5/15 ... yes
13/16 ... yes
5/17 ... yes
5/19 ... yes
5/20 ... yes
13/21 ... yes
5/23 ... yes
13/24 ... yes
5/28 ... yes
14/29 ... yes
5/31 ... yes
5/32 ... yes
14/33 ... yes
14/34 ... yes
4/37 ... yes
5/38 ... yes
5/39 ... yes
14/41 ... yes
13/42 ... yes
5/43 ... yes
5/44 ... yes
5/45 ... yes
20/46 ... yes
5/47 ... yes
13/49 ... yes
4/50 ... yes
5/51 ... yes
14/52 ... yes
13/53 ... yes
14/61 ... yes
14/62 ... yes
7/65 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.5 ? ... yes (2.5.3)
Git version >= 2.18.0 ? ... yes (2.18.1)
Git user has default SSH configuration? ... yes
Active users: ... 6
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished
Possible fixes
- Generate a new SSH Keypair and change it everywhere because your server was kinda important :/
- This only happens if I use a "Privately accessible deploy key". Doing the same steps (see above) with a "Publicly accessible deploy key" (added via the admin area) doesnt not result in an unuseable key and I can clone the "test2" project.
Edited by Matthias Kühne