Another idea, we currently have a 'Deploy User' that is added to each project as a 'Deployer' (role that only has read access to the repository).
Our production server is set up such that each site has its own user with a set of ssh keys. For each site we deploy we add that key to the Deploy User in Redmine. From there when we want to deploy changes we can just git pull and the server user can clone from the repository.
Herein lies the problem, because that deploy user has the keys for each deployed site, that account has read access to all our repositories which could be construed as a bit of a security risk. An alternative I considered is to make a new 'Deploy User' for each project, but we could end up with hundreds of user accounts which is a little unnecessary.
My proposed feature would be ability to paste a public key that can be used to deploy that repository alone, rather than adding it to a user then making that user a member of the project with read rights only. An added benefit would be having the ability to toggle write access to this key so that if a change is made on the public server that needs to be pushed to the repository it can be enabled temporarily.
As always, I appreciate your efforts with this plugin. I certainly makes our workflow so much nicer. Im happy to help where I can :)
Actually, this might work with a key placed on the settings page, just like with the various mirror keys (it could have a permissions box as to whether to allow R and/or W). Would there need to be more than one of these?
This would also align nicely with GitHub's per repository SSH key feature, which allows you to provide a unique public SSH key on a per repo basis. But they must be unique, so current approach of using a single SSH key for all chili/redmin repos doesn't work. Great for mirroring to GH.
Agreed, that was the intended purpose, thanks for providing clarity.
Ok. No objections to there being more than one deploy key? I was thinking of allowing you to name them and edit them from the settings page. Then, you can attach them to individual repos with R or RW access... Thoughts?
Can you guys start commenting on Issue #25? I think that both of these feature requests are for the same sort of thing. I would like to close this one and pick up things over there.
That sounds perfect, and would probably be handy in some cases (at least for me!)
re: #25, seem related but potentially different and maybe this ticker is clearer? Not sure re: an actual git user vs just unique deploy keys.
Seems like the only way that you would see a difference is if you wanted a unique key and had to go to a separate page to enter it... Otherwise, the only proposal here is to name the keys so that they could be reused. I was thinking that you could enter them on the repository page and be presented a default naming scheme for the keys (so that you wouldn't even have to come up with unique names?)...
Hm... Well, if you aren't using it, the presence of all of those keys would muck up the keydir. I suppose there could be a request to "generate unique key"....
Note that even GitHub has the ability to put in a bunch of DeployKeys in addition to the primary key.
I think the proposal here is fine, generating keys would be a nice to have, but not a show-stopper for me (since I typically do an ssh-keygen on the prod environment for each site and bring the .pub version back to redmine.
Edit: actually thinking about it, I probably wouldn't use the generated keys. As long as I could say that a given key has R or RW access to a repository (or more than one) that would fit my needs perfectly. Typically I wouldn't use more than one per repository, but I see no reason to not do it.
Are you still around? It turns out that I have an implementation of these "deployment keys". I can push it up tonight to my testing branch.
Ok. The testing branch now contains an implementation of deployment keys. The deployment keys can be shared among multiple repositories (if desired) or be unique per repository.
Please respond further on issue #25. I would like to get people to comment on the new implementation before I push to the master branch (don't forget to migrate_plugins!).