Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a development git server that deploys to a live server when the live branch is pushed to. Every user has their own login and therefore the post-receive hook which does the live deployment is run under their own user.

Because I don't want to have to maintain the users public keys as authorized keys on the remote live server I have made up a set of keys that 'belong's to the git system to add to remote live servers (In the post-receive hook I am using $GIT_SSH to set the private key with the -i option).


My problem is that because of all the users might want to deploy to live, the git system's private key has to be at least group readable and SSH really doesn't like this.

Here's a sample of the error:

XXXX@XXXX /srv/git/identity % ssh -i id_rsa XXXXX@XXXXX
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0640 for 'id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: id_rsa

I've looked around expecting to find something in the way of forcing ssh to just go through with the connection but I've found nothing but people blindly saying that you just shouldn't allow access to anything but a single user.

share|improve this question

3 Answers 3

up vote 3 down vote accepted

Here's a nice simple and secure way.

Create a new user for the ssh transfer, I'll call it git-sync. Create a similar user on the server with group membership for the git repository. Add the public key for sync-user into that users authorized_keys2 file. I'm assuming the git users are all members of the gitgroup. Make sure the git-sync user is also a member of this group.

Now edit your /etc/sudoers file to include a line like:

%gitgroup ALL=(git-sync) NOPASSWD: /usr/bin/git

This will allow any member of the gitgroup group to run the command /usr/bin/bit as git-sync without a password.

Now put something like this in your post-receive hook:

sudo -u git-sync /usr/bin/git push origin
share|improve this answer
    
This is better than what I was looking for, thanks! –  scjr Feb 7 '13 at 8:33
Permissions 0640 for 'id_rsa' are too open.

The private key must remain private. You shouldn't allow anyone to read it.

Because I don't want to have to maintain the users public keys as authorized keys on the remote live server I have made up a set of keys that 'belong's to the git system to add to remote live servers (In the post-receive hook I am using $GIT_SSH to set the private key with the -i option).

  1. setup a key pair to ssh from the dev to the production server
  2. in the post-receive hook script, try something like this:

    if [ "live" == "$branch" ]; then
        ssh -t user@prod "git --work-tree=... --git-dir=... checkout -f"
    fi
    
share|improve this answer
    
How can I "setup a key pair to ssh from the dev to the production server", this is what I am having a problem with. I already have 2 in place. –  scjr Sep 11 '12 at 9:00
1  
On the dev: ssh-keygen, ssh-copy-id user@prod. On the prod: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys. –  quanta Sep 11 '12 at 9:02
    
The problem is that there are multple users, therefore I have to repeat that for every user that wants to edit times by every project that exists on the server. –  scjr Sep 11 '12 at 9:13
    
No. You only need to setup only two more users: one to ssh from the dev to the prod, and another to run the git checkout... (on the prod). –  quanta Sep 11 '12 at 9:19
    
The post-receive hook (dev machine) is run by the user that is pushing a change (therefore under the users permission) so they will all have different keys, I can't help which user it will be. There are two post-receive hooks on two different servers in action. –  scjr Sep 11 '12 at 9:29

You CAN use group readable identity files, UNLESS you're the owner of the key. So, just set the identity file to be owned by, for example, the root user and then all your git repository users are set to go.

A nice benefit to this is that you don't need sudo - the solution will be more simple.

Note that this will run into the original problem again if you're using root to push to your git repo.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.