RFC patchconnect: add GIT_SSH_{SEND,RECEIVE}{,_COMMAND} env variables

Amend the long-standing logic for overriding the ssh command with GIT_SSH or GIT_SSH_COMMAND to also support e.g. GIT_SSH_SEND_COMMAND. The new specific send/receive variables take priority over the old ones, and fall back to the older ones if they exist.

This is useful for talking to systems such as Github or Gitlab that identify user accounts (or deploy keys) by ssh keys. Normally, ssh could do this itself by supplying multiple keys via -i, but that trick doesn't work on these systems as the connection will have already been accepted when the "wrong" key gets rejected.

This new feature is redundant to and less general than setting the GIT_SSH_COMMAND to the path of a script that's going to dispatch to ssh depending on what the second argument to the script is, e.g.:

    $ cat ./git-ssh-command
    #!/usr/bin/perl
    if ($ARGV[1] =~ /^git-upload-pack /) {
       system qw(ssh -i /some/ro/key) => @ARGV;
    } elsif ($ARGV[1] =~ /^git-receive-pack /) {
       system qw(ssh -i /some/rw/key) => @ARGV;
    } else { ... }
    $ GIT_TRACE=1 GIT_SSH_COMMAND="./git-ssh-command" git fetch
    10:22:39.415684 git.c:344               trace: built-in: git 'fetch'
    10:22:39.432192 run-command.c:627       trace: run_command: './git-ssh-command' '-G' 'git@github.com'
    10:22:39.434156 run-command.c:627       trace: run_command: './git-ssh-command' 'git@github.com' 'git-upload-pack '\''git/git.git'\'''
    Warning: Identity file /some/ro/key not accessible: No such file or directory.

However, I feel that this is a common enough case to be worth supporting explicitly, and such a script will also need to deal with arbitrary arguments fed via git-fetch's --upload-pack="...", and git-push's corresponding --receive-pack argument.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---

I'm not 100% sure about this one myself, but am leaning towards inclusion for the reasons explained above, and the patch is trivial enough that I think we can discuss whether it's worthwhile without test / documentation.

 builtin/fetch-pack.c |  2 +-
 builtin/send-pack.c  |  3 ++-
 connect.c            | 21 ++++++++++++++++++---
 connect.h            |  2 ++
 4 files changed, 23 insertions(+), 5 deletions(-)

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

You need to explain this a lot better than the above.  

I am sure systems such as Github have more than dozens of users who push over ssh and these users identify themselves by which key to use when establishing connection just fine (presumably by using a "Host" entry for the github URL in ~/.ssh/config), and presumably we are not sending "wrong" keys over there. So there needs to be a lot more clear description of the problem you are trying to solve in the first place.

On Wed, Jan 03 2018, Junio C. Hamano jotted:

Hopefully this is clearer, and depending on how the rest of the discussion goes I'll submit v2 with something like this in the commit message:

SSH keys A and B are known to the remote service, and used to identify two different users.

A can only push to repository X, and B can only fetch from repository Y.

Thus, if you have a script that does:

    GIT_SSH_COMMAND="ssh -i A -i B" git ...

It'll always fail for pulling from X, and pushing to Y. Supply:

    GIT_SSH_COMMAND="ssh -i B -i A" git ...

And now pulling will work, but pushing won't.

If you were to do, where C is a completly unknown key:

    GIT_SSH_COMMAND="ssh -i C -i A" git push X ...

It would work, since ssh wouldn't get far enough in the key negotiation to drop you into a shell. This is the case you had in mind, but is unrelated to the problem I'm trying to address.

I tested this on a Gitlab instance, but as far as I know this property is going to be intrinsic to anything that uses ssh in this way, i.e. once you get past the step where the server says "this key is OK" and drops you into a shell, it's not going to retry the whole negotiation with another key just because the command you ran exited with non-zero.

So now I just have a GIT_SSH_COMMAND that dispatches to different keys depending on the operation, as noted in the commit message, and I can assure you that without that logic it doesn't work.

I thought that use-case might be useful enough to be natively supported, since right now you either need to hack it up like that, or perform similar hacks with url/pushurl and ssh host aliases in your config.

On Thu, Jan 04, 2018 at 01:08:28AM +0100, Ævar Arnfjörð Bjarmason wrote:

I get that you may have two different keys to go with two different identities on a remote system. But I'm not sure I understand why "sending" or "receiving" is the right way to split those up. Wouldn't you also sometimes want to fetch from repository X? IOW, wouldn't you want to tie identity "A" to repository "X", and "B" to repository "Y?

You mentioned host aliases later, which is the solution I've seen in the wild. And then you can map each remote to a different host alias.

-Peff

On Thu, Jan 04 2018, Jeff King jotted:

That's badly explained, sorry, when I say "push" I mean "push and/or pull".

I don't know about Github, but on Gitlab when you provision a deploy key and associate it with a repo it must be *globally* rw or ro, there's no way to on a per-repo basis say it should be rw ro.

I have a job that's fetching a bunch of repos to review code in them (for auditing purposes). It then commits the results of that review to other git repos.

Thus I want to have a ro key to all those reviewed repos, but rw keys to the audit repo itself (and it'll also pull with the rw key).

Hence this patch, I thought *maybe* others would be interested in this since it seems to me to be an easy thing to run into with these ssh-key based hosting providers, but maybe not.

On Thu, Jan 04, 2018 at 11:10:17AM +0100, Ævar Arnfjörð Bjarmason wrote:

OK, that part makes sense to me.

But I'm not sure how your patch solves it. When you "git fetch" on the audit repo, wouldn't your GIT_SSH_RECEIVE_COMMAND kick in and use the wrong key? What am I missing?

-Peff

On Thu, Jan 04 2018, Jeff King jotted:

I add both the ro and rw key to some projects. Those are a tiny subset of the overall number.

Jeff King <peff@peff.net> writes:

Yup, I do agree that it is exactly the established solution for this kind of situation.