Score:1

Sudo Problem: Need Help with Github and My teams ssh keys

us flag

I cannot seem to find a question that completely relates to this. I'm using ubuntu 20.04 and my project is stored in /var/www/html/My_Project

Currently I work with a team of five and when we push or pull, we use sudo. When we do that our git repository then pulls via https and asks for credentials. As of today, GitHub no longer uses standard passwords for https, it is now a token that looks something like this "lksadknkasjvjkasd345kKja345neuhiehkjsdfn" (not actual token). This is a pain to keep and use over and over.

I setup a ssh key but had to set my key for the root user because no one has permissions to write to this directory. (I really like having to using sudo to make changes). So is there a way that we can still use sudo but use each team members key instead of just mine.

I see having everyone using my key as just a bad practice

Adding some clarification, I'm aware this is a bad setup. I'm not the guy that can change it. We have 5 devs with their own projects on this machine and every dev does not have access to all repos, so having 1 ssh key as root would not work.

We do have a production machine that is only managed by our CTO, "Code Review", when it happens, takes place on this machine before it goes to production.

So, please only answer the question if you have a solution or let me know if this is just a hopless endevor. #SolutionsNeeded

Bradley Armstrong avatar
us flag
We have an enterprise GitHub account and each have our own ssh key along with access to the repo. The problem is that I can only set one key for the project on our webserver. At least using the current method.
Bradley Armstrong avatar
us flag
It happens. Up to you on the removal
terdon avatar
cn flag
This is a very, very, very bad setup. You should move your repositories to your local $HOME directories and _not_ run git with sudo!
Score:2
cn flag

The bad practice here is that you have your repository in a non-writeable directory. From what you describe, it's even worse and you actually have everyone using the same local git repository! This sort of defeats the entire point of using git in the first place! If any of you screws up the repository, you can't fix it from someone else's local copy. You also can't work at the same time. This is really a very bad setup.

You say you like having to use sudo to make changes. I'm sorry but that just doesn't make sense at all. You control access by controlling what gets merged, not by controlling who can write to the local repository files! Plus, this is a horribly insecure approach: you're giving all of your developers root access to the machine just so they can write their code! I suspect you think this is increasing safety but the truth is that it is doing exactly the opposite.

Tell everyone to run a git clone in their home directories so everyone can have their own, local copy of the code. Next, configure your repository so that it doesn't allow merging without a reviewed pull request. This is something you want anyway.

This will not only let you use git to it fullest extent with everyone having a local copy of the repository which ensures code safety, and allows multiple people to work in parallel, on the same or different branches, it will also have the nice side effect of solving the problem you describe in your question: everyone can now add their own public ssh key to GitHub, store their own private ssh key in $HOME/.ssh/ and be able to push to the repository and open pull requests for the repository owner to review and merge.

Bradley Armstrong avatar
us flag
I will adjust my question a bit. This is the web testing machine pre production. We only want one copy on this machine.
terdon avatar
cn flag
@BradleyArmstrong then why is anyone working on the machine? Just have one copy, and allow root to checkout the relevant branch, why would you want devs to write directly into the repo? Each dev makes their changes in their local repo, pushes to the remote branch (ideally it will then go through a code review), then the branch is checked out on the target machine for deployment.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.