binfalse

This is a translation of my German entry.

Until now I managed my code/work with Subversion and all was very well, but I decided to move to a distributed revision control system. Calling spade as a spade my choice was Git.

After some tests I had the problem, that there is (basically) no central repository where everyone can commit changes, but I’m working with other guys on homework/projects. So how to centralize a distributed revision control system? Nothing easier than that!

Server set up

Software of choice is called gitosis, so install the following:

aptitude install git git-core gitosis

Gitosis will manage repositories and privileges on the repository server. The installation progress will add a new user to your system called gitosis (see /etc/passwd ). To initialize the master repository that will manage the rest just copy the SSH public key of your local account to /tmp/id_rsa.pub and do the following:

binfalse /home # su - gitosis
gitosis@binfalse:~$ gitosis-init < /tmp/id_rsa.pub
Initialized empty Git repository in /home/git/repositories/gitosis-admin.git/
Reinitialized existing Git repository in /home/git/repositories/gitosis-admin.git/
gitosis@binfalse:~$ exit

That’s it on the server, now you have a head-repository and you can manage everything on your local machine.

Managing the manage-repository

Right back on your local machine you also have to install Git:

aptitude install git git-core

Now you’re able to check out the previous created managing repository that knows your SSH key:

esmz-designz@abakus ~ $ mkdir git
esmz-designz@abakus ~ $ cd git/
esmz-designz@abakus ~/git $ git clone gitosis@HOST:gitosis-admin.git
Initialized empty Git repository in /home/esmz-designz/git/gitosis-admin/.git/
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 5 (delta 1), reused 5 (delta 1)
Receiving objects: 100% (5/5), done.
Resolving deltas: 100% (1/1), done.
esmz-designz@abakus ~/git $ l
total 12K
drwxr-xr-x 3 esmz-designz 4.0K 2009-08-23 01:19 ./
drwxr-xr-x 21 esmz-designz 4.0K 2009-08-23 01:14 ../
drwxr-xr-x 4 esmz-designz 4.0K 2009-08-23 01:19 gitosis-admin/
esmz-designz@abakus ~/git $ cd gitosis-admin/
esmz-designz@abakus ~/git/gitosis-admin $ l
total 20K
drwxr-xr-x 4 esmz-designz 4.0K 2009-08-23 01:19 ./
drwxr-xr-x 3 esmz-designz 4.0K 2009-08-23 01:19 ../
drwxr-xr-x 8 esmz-designz 4.0K 2009-08-23 01:19 .git/
-rw-r--r-- 1 esmz-designz 89 2009-08-23 01:19 gitosis.conf
drwxr-xr-x 2 esmz-designz 4.0K 2009-08-23 01:19 keydir/

The directory keydir holds known SSH keys from users that will work with you, gitosis.conf is the managing file. It is nearly empty on creation and may look like this:

[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = esmz-designz@abakus

To add a new repository just type something like this:

[repo RepositoryName]
owner = you@yourhost
description = some description words

And to create a new group of users:

[group GroupName]
writable = RepoTheyCanWrite1 RepoTheyCanWrite2
readonly = RepoTheyCanRead1 RepoTheyCanRead2
members = user1@host1 user2@host2

New users should give you their public key, so you can save it in the keydir directory with a name like user@host.pub . To commit the changes you’ve made type the following:

esmz-designz@abakus ~/git/gitosis-admin $ git commit -a
[master 51cdf92] Created repository test.
1 files changed, 4 insertions(+), 0 deletions(-)
esmz-designz@abakus ~/git/gitosis-admin $ git push

Now everybody that was enabled is allowed to checkout your projects. To initiate a new project you can do the following:

esmz-designz@abakus ~/git/gitosis-admin $ cd ..
esmz-designz@abakus ~/git $ mkdir test
esmz-designz@abakus ~/git $ cd test/
esmz-designz@abakus ~/git/test $ git init
Initialized empty Git repository in /home/esmz-designz/git/test/.git/
esmz-designz@abakus ~/git/test $ git remote add origin gitosis@HOST:test.git

To commit a first file:

esmz-designz@abakus ~/git/test $ echo "Usain Bolt" > WM_BERLIN
esmz-designz@abakus ~/git/test $ git add WM_BERLIN
esmz-designz@abakus ~/git/test $ git commit -m "Start der ersten Revision"
[master (root-commit) 444915d] Start der ersten Revision
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 WM_BERLIN
esmz-designz@abakus ~/git/test $ git push origin master:refs/heads/master
Initialized empty Git repository in /home/git/repositories/test.git/
Counting objects: 3, done.
Writing objects: 100% (3/3), 245 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To gitosis@HOST:test.git
* [new branch] master -> master
esmz-designz@abakus ~/git/test $

Voila, there is your repository! Check it out, change it, branch it, you know what to do!

Publish a repository

With this configuration only you and a bunch of people can see what you are doing in your spare time, but what if you want to publish you work? You can create a git daemon that listens on port 9418 of your server, waiting for a user who wants clone your code:

binfalse /home # sudo -u gitosis git-daemon --base-path=$GITOSISHOME/repositories --verbose --detach
binfalse /home # ps -ef | grep git
gitosis 3216 1 0 00:57 ? 00:00:00 git-daemon --base-path=$GITOSISHOME/repositories/ --verbose --detach
binfalse /home #

This service will serve any repository content if you create a file called $REPOSITORYHOME/git-daemon-export-ok in this repository (content isn’t necessary). Everybody knows that such a daemon tends to die sometimes, so I created a cronjob:

*/5 * * * * [ -z `pidof git-daemon` ] && sudo -u gitosis git-daemon --base-path=$GITOSISHOME/repositories/ --verbose --detach

Now everybody can clone repositories with that special file that allows public cloning by:

git clone git://HOST/REPOSITORY.git

That’s it! not that difficult but one has to know what to do! Have fun with your repository.

This is a translation of my German article.

SSH is a secure way to connect to a remote system, e.g. for administration or remote working. The communication between these two workstations is encrypted, so an enemy is not able to intercept/spy on the transferred data.

Although the password that is sent to access the other system is encrypted, it’s still possible to brute force it. To decrease this risk one can turn off password authentication and just allow the authentication via SSH keys, so that the access is only possible for people that have a specific private keys. It is much harder to guess such a private key than guessing a password.

To create such a key pair, containing a private and a public key, just run ssh-keygen -t rsa -b 4096 in your terminal. This command will create an RSA-key width 4096 bits (the more bits the harder to guess the key). The output may look like this:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
16:59:cb:9f:55:b1:39:ee:b3:72:14:19:13:5c:60:4d user@abakus
The key's randomart image is:
+--[ RSA 4096]----+
|            . +*E|
|         + . . =+|
|          o o .++|
|     .  .    o.o.|
|           S o ..|
|         . ..    |
|        .o       |
|       .       .o|
|        o.       |
+-----------------+

Congratulations, your are now owner of a 4096 bit SSH-key! It is not necessary to assign a passphrase, so you can connect to the server without any password. But if anyone can get access to your private key he is also able to connect to any server that knows your public key! So it is very insecure and I recommend using a passphrase. For more options see man ssh-keygen.

If you now take a look in your $HOME/.ssh/ directory you’ll find two keys, a public key named id_rsa.pub and a private key id_rsa. This private key is just for you, don’t share it with anyone!

To publish the public key, you can use the ssh-copy-id tool:

user@abakus ~ $ ssh-copy-id user@192.168.0.111
The authenticity of host '192.168.0.111 (192.168.0.111)' can't be established.
RSA key fingerprint is 34:cd:e7:95:48:75:d4:16:86:84:19:f0:b4:d3:2c:ad.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.111' (RSA) to the list of known hosts.
user@192.168.0.111's password:
Now try logging into the machine, with "ssh 'user@192.168.0.111'", and check in:

.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

All that it does is appending the contents of your public key to the $HOME/.ssh/authorized_keys file of the user on the remote system (here remote is 192.168.0.111). If you don’t have the ssh-copy-id tool, you can do it manually but copying the contents of id_rsa.pub to the authorized_keys file of the remote user..

At the next login I don’t have to provide the password to the remote account, I only need the passphrase for the private key:

user@abakus ~ $ ssh user@192.168.0.111
Enter passphrase for key '/home/user/.ssh/id_rsa':
Linux siduxbox 2.6.30-4.slh.1-sidux-amd64 #1 SMP PREEMPT Sun Aug 2 09:58:18 UTC 2009 x86_64
Last login: Wed Aug 19 12:12:18 2009 from 192.168.0.55
user@siduxbox ~ $

If you didn’t supply a passphrase for the key you’ll never get asked for one.

Last but not least we can disable the password authentication with the following settings in /etc/ssh/sshd_config :

PasswordAuthentication no
UsePAM no

From now on, only people that have private keys, compatible to those public keys stored in $HOME/.ssh/authorized_keys on the server, can access the remote machine.