[security] deployment keys access to repositories

[gituser]

hello.

i've been using for quite some time older version of your's redmine_git_hosting plugin with redmine 2.2

yesterday i've decided to give a go with this new version and had some problems migrating from older version.

mainly it was because of the new scheme of keys naming, e.g:

redmine_deploy_key_10@....
or
redmine@....

the problem here is in gitolite.conf you have access keys without @ at all, so if you add just 1 deployment key to ANY project it gets access to all projects:

repo    somerepo2
  RW+                            = redmine_user2 redmine_user2_deploy_key_10
  RW                             = redmine_user
  config redminegitolite.projectid = somerepo2
  config redminegitolite.repositoryid = 
  config redminegitolite.repositorykey = xxx2
  config http.uploadpack = true
  config multimailhook.enabled = false

repo    somerepo
  RW+                            = redmine_user2 redmine_user2_deploy_key_10
  RW                             = redmine_user
  config redminegitolite.projectid = somerepo
  config redminegitolite.repositoryid = somerepo
  config redminegitolite.repositorykey = xxxx
  config http.uploadpack = true
  config multimailhook.enabled = false

keydir of gitolite-admin contains this:

redmine_user2_deploy_key_10@redmine_1412321657_532576.pub
redmine_user2_deploy_key_10@redmine_1412226560_727957.pub

I'm using gitolite gitolite3 v3.6.1-0-g3455375 on git 1.7.2.5
also tested on v2 and it was pretty much same..

[gituser]

any update on this?

[n-rodriguez]

Hi there!

I'm sorry, I don't see the point...
Actually, you cannot have this :

redmine_user2_deploy_key_10@redmine_1412321657_532576.pub
redmine_user2_deploy_key_10@redmine_1412226560_727957.pub

since the key name is computed and incremental.

[gituser]

hi, finally you got back to me, thanks :)

it happened after migration from old redmine_git_hosting supported by kubitron.

it might be an issue in your migration script.

i've tried creating new keys they seems to be working normal so I guess I have to-recreate all SSH-keys at some point or is there more elegant way of renaming them?

[n-rodriguez]

redmine$ RAILS_ENV=production bundle exec rake redmine_git_hosting:rename_ssh_keys

[gituser]

unfortunately it didn't work out...
keys are still with @ sign, I'll try to create them manually and checkout..

[n-rodriguez]

keys are still with @ sign, I'll try to create them manually and checkout..

the @ in filename is normal : in 0.7 branch SSH keys are stored in a single directory in a 'flat' design so we need to be sure of the uniqueness of the keys : thus the @ with the timestamp.

[gituser]

problem is:
authorized_keys generated without @, so gitolite basically adds redmine__ for each repo without particular timestamp, so some keys granted to specific repo gets access to all repos..

[n-rodriguez]

so some keys granted to specific repo gets access to all repos..

I don't see how. Do you have a real example?

[gituser]

ok, here is how to reproduce it:

1. create a deployment key
2. it will be like keydir/redmine_deploy_key@redmine_.pub
3. for some reason it adds number of the existing before key, so for example if you had:
   keydir/redmine_user_deploy_key_11@redmine_123123123_1231.pub and earlier you had a key with the same username and number but different timestamp keydir/redmine_user_deploy_key_11@redmine_132312315_35344.pub assigned to different project, in the end your created key will get access to all repositories because gitolite cuts off everything after @ sign.

[gituser]

i've just tested this by creating 2 deployment keys, and one of the keys matched the same number (11) of the existing keys for some reason, so after creation it's already have access to all projects where redmine_user_deploy_key_11@.* is specified.

[n-rodriguez]

I've done the same and here what I get :

-rw-r--r-- 1 redmine-jbox redmine-jbox 403 Dec 20 22:33 redmine_nicolas_deploy_key_1@redmine_1419111213_815098.pub
-rw-r--r-- 1 redmine-jbox redmine-jbox 403 Dec 20 22:34 redmine_nicolas_deploy_key_2@redmine_1419111255_425368.pub

[n-rodriguez]

On Gitolite side :

repo    blabla
  R                              = DUMMY_REDMINE_KEY gitweb
  config redminegitolite.projectid = blabla
  config redminegitolite.repositoryid = 
  config redminegitolite.repositorykey = KWNEKEXAISXCLTHKARVRKDUHEMGFMVDJOPOVRPSWSKYYWEROOVDNHABSDDHIYHFHSBKYANOPVTYWSBRT
  config http.uploadpack = true
  config multimailhook.enabled = false

repo    child-project/subrepository
  RW+                            = redmine_admin
  R                              = gitweb
  config redminegitolite.projectid = child-project
  config redminegitolite.repositoryid = subrepository
  config redminegitolite.repositorykey = INNURFCXJQKCRYTLIMXADOOAQXODEMWALFYXMIKPNTQCHEXMQNKLFAEMPNGFSUSGGIFHNXMKMSNRTEMWLYVWUDHLFVPWVXOFJX
  config http.uploadpack = true
  config multimailhook.enabled = false

repo    gitolite-admin
  RW+                            = redmine_gitolite_admin_id_rsa

repo    parent-project
  RW+                            = redmine_admin redmine_nicolas redmine_nicolas_deploy_key_1
  R                              = gitweb
  config redminegitolite.projectid = parent-project
  config redminegitolite.repositoryid = 
  config redminegitolite.repositorykey = YSRBBWXIOPXHGFPIEYDLDIROWTKVMYARTHODOLYEJVAXLTYNRBUKQTMTXNGHGXYYCSBHJOYTWIMTRGUNSWKUHFVCJNWWFMWMCWRKPWJAUEOYBRWWVDHLTQOGSWWX
  config http.uploadpack = true
  config multimailhook.enabled = false

repo    parent-project/parentrepo2
  RW+                            = redmine_admin redmine_nicolas
  R                              = gitweb redmine_nicolas_deploy_key_2
  config redminegitolite.projectid = parent-project
  config redminegitolite.repositoryid = parentrepo2
  config redminegitolite.repositorykey = QRQXJNEXMWCFQULOSBWMQEMOKYYJVREBQAIQBXIPXVCXPTYPSPRCJWBSPNWYBSASRPYNBSPEGQXNUHXFTUTLFHEBJBLGNGBKNXOOSLMUKYOMGY
  config http.uploadpack = true
  config multimailhook.enabled = false

[gituser]

hey Nicholas

What I meant the issue is reproduced fully if you migrate from older version of plugin maintained by kubitron.

Can you check?

[gituser]

I've done the same and here what I get :

Well, first deployment key I've just generated had the same number (11) I had before for some reason..
Next generated development key had 12 so it's fine..

[gituser]

OK, I think I've found what is the issue.

Here is how to properly re-produce:

1. Create some deployment key (if you didnt had any key before it should be redmine__deploy_key_1
2. Create another key (should be redmine__deploy_key_2)
3. Add another key (should be redmine__deploy_key_3)
4. Now delete 2nd key (redmine__deploy_key_2)
5. Add a new key and surprise!! it's going to be (redmine__deploy_key_3@....) so there you go it's going to duplicate access as 3rd key.

In short: problem is because you're getting amount of user keys and add of total to the key.. I don't get why do you add @ instead of regular format: redmine_deploy_key_timestamp.pub.

[n-rodriguez]

Ok now it's clear :)

I don't get why do you add @ instead of regular format: redmine_deploy_key_timestamp.pub.

#22

[gituser]

to avoid collisions I highly recommend to add _timestamp as well there in the key name..

I don't really get why would you need to predict username key? What's the point?
If you need to ID specific key you can add field in the redmine and display actual key name (.pub) ?

[n-rodriguez]

#22 (comment)

[n-rodriguez]

to avoid collisions I highly recommend to add _timestamp as well there in the key name..

I think it would be better to improve set_identifier method.

[n-rodriguez]

If a deployment key with redminedeploy_key_<id> already exists just add 1 and retry.

[n-rodriguez]

This is fixed in v0.7.9 branch.

[gituser]

updated to v0.7.9

will report asap how it's working

EDIT: seems to be working, thanks!

[n-rodriguez]

EDIT: seems to be working, thanks!

You're welcome :)