2

I have a remote machine where multiple developers work on the same repository. We use gitolite and SSH keys to manage git access.

As for now we code on the local machines, commit, push, pull remotely and test. It works, but is time consuming and annoying.

If we edit code on remote repo, we can commit and push, forwarding agent gives correct access rights to repository, but still name and email is the one configured on the server.

Tried setting up environment variables:

GIT_COMMITTER_NAME=name
GIT_COMMITTER_EMAIL=mail@example.com

But it still uses data from git config. If I unset those, git complains about that during commit.

Is there a way to configure email and name independently for each user, eg. through ssh keys passed by forwarding agent?

A nasty workaround is to mount remote directory locally and then commit on local machine. Nasty and takes ages.

  • 2
    "Is there a way to configure email and name independently for each user, eg. through ssh keys passed by forwarding agent?" -- that hardly reads workflow to me – gnat Jan 29 '16 at 18:25
  • 2
    As for now we code on the local machines, commit, push, pull remotely and test. It works, but is time consuming and annoying. So why can't you test locally? – tkausl Jan 29 '16 at 18:46
  • Well, I guess it is a subject of opinion, but nevertheless, it does not fit any other option from your link. @tkausi sometimes we can, but most of the time it involves plenty of hardware that is server side – kszonek Jan 29 '16 at 18:47
  • 2
    Have you tried scripting this step: commit, push, pull remotely and test ? – dcorking Jan 29 '16 at 19:11
0

SSH Agent forwarding is a potential security risk:

The problem is that while you're connected to host A, a forwarding socket will be set up so that the SSH client on host A can connect to the ssh-agent on your workstation to perform authentication on its behalf. This means that anyone with sufficient permission on host A will be able to use that socket to connect to and use your local ssh-agent. It could be the root user or anyone else who managed to compromise host A. The result is that the user would be able to impersonate you to any host as long as you're connected to host A.

At any rate, if you need to fix this, first check to see if the key is listed:

$ ssh-add -l

Then, if you don't see your key listed, add it by

ssh-add ~/.ssh/identity

And add the public key to gitolite:

On the server you have appended this file to ~/.ssh/authorized_keys. Or you ran something, like the gitolite setup step during a gitolite install, which should have done that for you.

References

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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