Secure Git Server – Preventing Git User Logging in via SSH

A short tutorial detailing the steps required to quickly setup a secure git server that doesn’t allow the git user access via ssh – in other words, git commands work & one may use keys for password-less access, but you may prevent any / all ssh keys from being able to log into your server as the `git` user.

On your workstation:

Each user needs to generate an RSA key. This can be done like so (*nix)

$~ ssh-keygen -t rsa

Copy your public key (not your private key – that should never leave your machine!)

$~ scp ~/.ssh/ <username>@<server>/tmp/

On your server

Install git

$~ yum install git

Create git user

$~ useradd git

Create the git user’s `.ssh` directory

$~ mkdir /home/git/.ssh

Add your workstation’s public key to the git user’s authorized_keys file

$~ cat /tmp/ /home/git/.ssh/authorized_keys

Test what you’ve done so far by attempting to ssh to your server from your workstation with

$~ ssh -v git@<server>

Assuming that worked fine, create a git repository on your server

$~ mkdir /home/git/new-repo.git
$~ cd /home/git/new-repo.git
$~ git --bare init

Now on your workstation, add this repository, add the remote, create a file, add & commit it, then push it to the server

$~ mkdir ~/new-repo
$~ cd ~/new-repo
$~ git init
$~ git remote add origin git@<server>:new-repo.git
$~ touch README
$~ git add README
$~ git commit -m 'Added README file, first commit'
$~ git push origin master

Assuming that went well, you’re nearly done. Now all we have to do is prevent anyone from being able to ssh into your server with the git user. What we need to do is to lock down the relevant ssh keys. This is accomplished on your server by prepending the following string to the git user’s authorized_keys entry for each key we don’t want to have ssh access

command="perl -e 'exec qw(git-shell -c), $ENV{SSH_ORIGINAL_COMMAND}'"

For example, change the current authorized_keys file from

ssh-rsa <rsa-key> <username>@<hostname>

To the ‘locked down’ version

command="perl -e 'exec qw(git-shell -c), $ENV{SSH_ORIGINAL_COMMAND}'" ssh-rsa <rsa-key> <username>@<hostname>

Any attempt to login to your server from your workstation should now fail. You may now collect authorized keys from your developers and add them (not forgetting to prepend the ‘lock down’ line!) to the git users’s authorized_keys file.

Comments (1) | Trackback

Atheros Drivers – In A Repository!

Now, instead of manually installing Atheros drivers, I can install them from ELRepo!

First, find the device id for the network adapter:

for BUSID in $(/sbin/lspci | awk '{ IGNORECASE=1 } /net/ { print $1 }'); do /sbin/lspci -s $BUSID -m; /sbin/lspci -s $BUSID -n; done

It’ll give output like:

02:00.0 "Ethernet controller" "Atheros Communications" "Atheros AR8132 / L1c Gigabit Ethernet Adapter" -rc0 "Giga-byte Technology" "Unknown device e000"
02:00.0 0200: 1969:1062 (rev c0)

The number we want is on the second line, in this case it’s “1969:1062″.

Copy that, then go to the ELRepo Device ID page to find which driver package to use. In this case, We find:

pci 1969:1062 kmod-atl1e

Now just follow the instructions to add the repository and install the driver package on the ELRepo main page.

For me, using CentOS 5.5:

rpm –import
rpm -Uvh

Then finally installing the driver package:

yum –enablerepo=elrepo install kmod-atl1e

No comments | Trackback

Atheros Drivers Centos 5.5

Servers went down. We think it had something to do with the network hardware and / or the drivers ( Atheros AR81Family ) and their compatibility ( or lack thereof ) with our Centos 5.5 boxes.

As our servers are in the PRC, I can’t physically touch them – luckily we have an excellent team of capable admins who can. After being alerted that the servers were down, they went to the datacenter and managed to convince the machines to work.

I’d noticed some similar issues with our development server ( same hardware ). The server crashed quite often when using rsync to backup directories with a large amount of small files, and would need to be hard-reset. Not cool.

So I spent some time tracking down the driver download page – it’s hidden :( and updated our network drivers. We were 5 versions behind! Here it is:

Atheros AR81Family Drivers

I’ve spent the day trying to put the development server under as much stress as possible, using ab, flood and rsync. So far it hasn’t crashed, which is a good sign.

I had a little trouble installing flood on my work machine – ran into errors with Macports installing db46, required for flood.

Comments (1) | Trackback

Make Service Run at Startup – CentOS

Note to self: Stop forgetting this!

Make a service start at boot:

chkconfig httpd --add
chkconfig  httpd  on --level 235

Check if a service has been set this way:

chkconfig --list httpd

From Enabling and disabling services during start up in GNU/Linux.

What is that –level ### stuff?

ID Description
0   Halt
1   Single-User mode
2   Multi-user mode console logins only (without networking)
3   Multi-User mode, console logins only
4   Not used/User-definable
5   Multi-User mode, with display manager as well as console logins (X11)
6   Reboot

Thanks Wikipedia for the table!

Most users run X from one of two runlevels: 3 or 5. Runlevel 3 places your system in multi-user mode with full networking capabilities. The machine will boot to a text-based login prompt with all necessary preconfigured services started. Most servers are run in runlevel 3, as X is not necessary to provide any services utilized by most users. Runlevel 5 is similar to 3, except that it automatically starts X and provides a graphical login screen. Many workstation users prefer this method, because it never forces them to see a command prompt.

From The Official Red Hat Linux Reference Guide.

No comments | Trackback

MyTop, Top for MySQL

ECPod must have jumped a bit in popularity, as today, while skim-reading the error log I noticed a lot of these:

[exception 'PDOException' with message 'SQLSTATE[00000] [1040] Too many connections' in ../includes/classes/db/connection.php5

My initial reaction was to simply increase the connection limit in /etc/my.cnf. After doing that I also went through parts of our codebase that create new DB connections, and refactored them so that they now reuse an existing connection if possible – should have been that way from the start, but things like that can be missed when under a hectic development schedule.

Damage control over, I ran `top` to check the load of our database master. This made me wonder if there is a similar tool available that allows monitoring of a mysql instance.

There is, it’s called mytop. It’s even in the CentOS repository!

A quick yum install later, and I am now able to monitor mysql’s performance in real-time, just like I can for the whole server with top.

Here’s a screenshot of it in action:

MyTop Screenshot

Great to be able to see queries per second, average queries per second, total queries, mysql uptime etc all in one place, and it’s quite interesting to watch if for a few minutes to see the queries as they’re being made. Also shows key buffer efficiency (how often keys are read from the buffer rather than disk).

In all, very helpful!

Comments (4) | Trackback