GitLab

Created by: kohenkatz

I have some users who accidentally bypassed the uniqueness check for SSH keys by putting in the same key with a different comment at the end as their own key and as a deploy key, and then were unable to push to the repository because the system used the read-only permissions of the deploy key.

Steps to Reproduce

1. Go to a project and add a deploy key for the project.
2. Log in as a user who uses that project and add the same SSH key on the user profile page. Before clicking submit, add the word "test" to the end of the key's comment so it will pass the GitLab duplicate check.
3. Clone the repository over SSH.
4. Make a change, commit, and attempt to push.

(Note that it seems the deploy key must be added first, I'm guessing because the server reads authorized_keys in order.)

Expected Behavior I would think that SSH keys should be checked for duplicates with the comment on the end stripped off so that we are actually comparing only the key itself, not the arbitrary comment after it.

Observed Behavior Some git client versions show the following message:

fatal: The remote end hung up unexpectedly

And others show this message:

fatal: Could not read from remote repository.

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

Environment Check

git@vis:~/gitlab$ bundle exec rake gitlab:check RAILS_ENV=production 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.4.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? ... yes post-receive hooks in repos are links: ... Class.CMSC435 / Baloo ... repository is empty Research.DistributedSystems / Reconfiguration Framework - CSharp ... repository is empty Moshe Katz / Reconfiguration CSharp WIP ... ok MKatz Testing / Test Project 1 ... repository is empty Research.DistributedSystems / remotify ... ok Research.Exploits / BugBox ... ok Research.DefectMetrics / Papers ... ok Research.DefectMetrics / SynDefectData ... ok Research.DistributedSystems / POLYLITH-legacy ... ok Research.DistributedSystems / Mikasher ... repository is empty Research.DistributedSystems / DispatchClient-Java ... ok Research.DistributedSystems / monitor ... ok

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? ... Research.DistributedSystems / Reconfiguration Framework - CSharp ... can't create, repository is empty Research.DistributedSystems / remotify ... yes Research.Exploits / BugBox ... yes Research.DefectMetrics / Papers ... yes Research.DistributedSystems / DispatchClient-Java ... yes Research.DistributedSystems / monitor ... yes 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

Version I originally encountered this issue in 5.2 and was able to reproduce after upgrading to 5.3.

Last commit SHA1 fragment on help page is: e1c473c1

My Setup

System information System: Ubuntu 12.04 Current User: git Using RVM: no Ruby Version: 1.9.3p0 Gem Version: 1.8.11 Bundler Version:1.3.5 Rake Version: 10.0.4

GitLab information Version: 5.3.0 Revision: e1c473c1 Directory: /home/git/gitlab DB Adapter: mysql2 URL: https://para.cs.umd.edu HTTP Clone URL: https://para.cs.umd.edu/some-project.git SSH Clone URL: [email protected]:some-project.git Using LDAP: no Using Omniauth: no

GitLab Shell Version: 1.4.0 Repositories: /home/git/repositories/ Hooks: /home/git/gitlab-shell/hooks/ Git: /usr/bin/git

GitLab HTTP(S) is proxied through Apache to Puma on tcp://127.0.0.1:9292.

Possible fixes I can think of several options, but I'm not sure which one is the best.

• Strip comments from SSH keys before storing. This can mean either throwing the comments out (though I don't think I like that idea) or just storing them separately.
• Store and compare fingerprints of keys instead of comparing the keys themselves. (Note that the output of ssh-keygen -lf includes the comment, so it must be stripped before it is stored.)