SSH does not allow the use of a key with group readable permissions

Question

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.

Solution 1

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

Solution 2

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.

Solution 3

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
   

Comments

[Jessie Ross]

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.

[Greg Petersen]

On the dev: ssh-keygen, ssh-copy-id user@prod. On the prod: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys.

[Jessie Ross]

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.

[Jessie Ross]

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.

[Jenny D]

If you don't want to spend a lot of time fixing public keys on the server, how about just giving the same private key to every user and letting them set it up in their own .ssh directory?

[Jessie Ross]

This is better than what I was looking for, thanks!

[Ian McGowan]

This is awesome, and much better than the "don't do that" answers. Thanks!