Overview
Over the past week or so I've been setting up remote git repositories on my slice. I figured it would be helpful to put together a post regarding what I've found to be the right way to set up remote git repos. The info in this post is basically collected from several blogs and articles, but I've yet to see all of it in a single post.
Before we get started, I'm going to make a couple of assumptions:
- You're running ubuntu
- You have ssh access to your box
- You have access to a user on the sudoer list
- You have git installed on your server and your client machine
- You've generated a public/private key and it's in the standard location
Ok, enough with the chitchat, let's just get started.
Adding the git user
1. Create a git user on your server
2. Create your .ssh folder and authorized_keys file for the git user
3. Next, we need to copy the public key from our client system and add it to the authorized_keys for the git user on the server.
4. Because we're going to be giving anyone access to the git user who needs access to the git repos, we want to restrict the actions the git user can take. To do so, we'll set the git users shell to git-shell. First, log back into your server on a user with sudo access (not the git user) and do the following:
Creating a new git repo
So we've created our git user and now we'd like to create a new repository that we can use from the clients. It's actually really simple. We basically create a folder on the server in our git user's home directory named whatever we'd like the repo to be named and them we initialize it as a bare git repo. One thing to keep in is that all these commands will be performed from a user that has sudo access and is NOT the git user. Because we've set the git user's shell to git-shell, we can no longer switch to that user or ssh in as them.
First Commit to the Repo
After initializing the repo, we're going to do a first commit from our client machine. The first commit is slightly complicated, but after you'll be all set to go.
Cloning your Repo
Our repo is now all set to clone! On our client, we could futz around with the .git/config to make our master branch track the origin, but if we clone the repo it does it for us! So, we'll just delete the directory we've just created and reclone the repo. That way, we don't have to remember how to set up the .git/config file (and I'm lazy).
And that's really all there is to it. If you'd like to give someone else access to your git repo, simply add their public key to authorized_keys. Keep in mind that with this setup, all users will have access to all git repos you create in the git user's home directory. I'll talk more about giving different access in a later post. Hope this helps you all getting git remote repos up for all your projects.
Update: Now uses ssh copy-id to copy public key to the remote server.
10 comments:
This approach (real Unix user per Git user) will work; but with a tiny bit more config work at the start, I think you will find it much more pleasant to manage a set of Git uses and repos with Gitosis. Some URLs about getting it going:
http://vafer.org/blog/20080115011413
http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
kyle: I haven't looked into Gitosis, I'll take a look soon. I liked this approach for me because it caused me to learn more about my ubuntu system and the way sites like github.com work. Thanks for the tip.
I am somewhat nervous about trusting this shared gituser account with sudo/git-shell. I'd prefer something like this webdav setup. I suppose the "right" way can mean different things for different objectives.
todd:
The webdev setup is definitely interesting, and you're definitely correct that "right" differs from situation to situation. In this case, though, we aren't giving sudo access to our git user and the git-shell stops the user from doing anything other than performing git commands.
I've seen Git have a lot of problems w/ webdav (certainly webdav's fault ;), I would recommend against it. Gitosis is ubiquitous for self-hosting, otherwise GitHub for third party hosting.
Thank you thank you thank you. I've been beating my head against a wall with weird gitosis problems when all I need *right now* is a working repository *right now*. This worked wonderfully and now I can actually get something done.
I look forward to using gitosis once I get everything running, but this is definitely the KISS method.
One little time saver would be to determine which path git-shell has prior to adding the git user, and then passing in that value when adding, like so:
ChipCastle /git: which git-shell
/usr/local/bin/git-shell
ChipCastle /git: sudo adduser --shell /usr/local/bin/git-shell git
This would save you from editing /etc/passwd altogether.
Thank you soo much for this tutorial. Gitosis might be a great tool to some but it is a PAIN IN THE A** to configure and use...on top of that, there is no in-depth documentation on tackling problems in various situations. If you're gonna open source something, do it right! Sorry for yappin' but ure tutorial really helped me out. Thanks!
thanks very much for this tutorial.
I think if you add this to the .git/config then you don't need to rm -rf and clone:
[branch "master"]
remote = origin
merge = refs/heads/master
@foo yep, you're exactly right. i'm just too lazy to remember this, so i always reclone :)
Post a Comment