[Inori]

Preface: this tutorial assumes you're already somewhat familiar with Git, standard Linux commands, and whatever distro you're using. I'm not explaining why certain things are done in whatever way, just showing you so you can explore.

As a start, Git is more or less powered by SSH. SSH is a flexible, powerful, and extremely useful utility for remote productivity. It's fairly easy to install and configure and it's system-agnostic, meaning (in this case) that the configs are exactly the same across any distro.

Installation

---

The first step is installing the OpenSSH server (and git if you don't yet have it). It's listed as "openssh-server" in the core repositories of the apt, yum, and pacman package managers.

Code:

# debian
sudo apt-get install openssh-server
# RHEL
sudo yum install -y openssh-server
# Arch
sudo pacman -S openssh-server

The git slave

---

Ok, that title sounds a little harsh, but this is Linux: we talk about killing children and nobody bats an eye Jokes aside, we need to create and configure a dummy user for everything git-related. I'm doing this setup in Ubuntu since it's the most recognizable format, and going through examples on the same host because it's convenient.

Creating the user
We need to create a user with their own home folder and user group. In Ubuntu, this is more or less the default behavior, but it looks a little different for other distros.

Code:

# ubuntu
sudo adduser git
# CentOS, Arch, etc...
sudo useradd -m -d /home/git git
sudo passwd git

Configuring SSH
Now we need to set some rules for people attempting to SSH into our git account. Become the git user, create a ".ssh" config directory in the git user's home, add a keys file, and set permissions.

Code:

sudo su - git
cd
mkdir .ssh
touch .ssh/authorized_keys
chmod 700 .ssh

Now that we have our config directory, we can copy the SSH keys we want to allow into the keys file (generate yours by running "ssh-keygen -t rsa"). This is what's used in place of a password. If the person trying to connect isn't listed in the keys file, they must know the password to login (which will be the case when copying keys if yours isn't there to begin with).

Code:

ssh-copy-id git@localhost

Extra protection (optional)
If you decide to host this git server and make it public, it's a good idea to change the git user's shell to the one that comes with git itself. The git shell is a restricted login shell for git-only access, essentially meaning nobody who logs in as git (even you) can do anything not git-related (more about this here). You can do this as follows:

Code:

sudo chsh -s /usr/bin/git-shell git

Using the server

---

Now that we have our user, we can start using our git server (on some distros, namely Arch and CentOS in my experience, you may need to start the ssh daemon. This is usually done with "systemctl start sshd"). Git (the tool, not our user) has no way of automatically creating remote repositories, so this still has to be done by hand. Creating a new remote and adding it to a local repo is done like so:

Code:

# creating the remote
mkdir /home/git/whatever.git
cd /home/git/whatever.git
git init --bare # bare repo: no .git directory inside

# adding to local
cd ~/my-git-project
git remote add my-server git@localhost:whatever.git

It goes without saying that this is a very basic setup, but it does the job as well as any.

[insidious]

Nailed it, definitely gets the job done. It's good for creating private projects that you wouldn't want hosted with a third-party.

As I see it, there's not harm in putting your project up on Github and opening it up to the Open Source Community. If you are doing something for a private company, or maybe *cough* something slightly illegal *cough* probably best to create a nice private github on your own/company server for full control