{"thread":{"id":"34910","subject":"Specifying a private key when connecting to a remote SSH repo","startedAt":"2013-09-11T23:19:00Z","lastAt":"2013-09-12T17:48:31Z","messageCount":5,"participants":["Breck Yunits","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"227496","messageId":"CAOgHByvTtNDho50B+pECMeXkq=3FF8EheFbP4iQbKYTiAPTwYw@mail.gmail.com","threadId":"34910","inReplyTo":null,"subject":"Specifying a private key when connecting to a remote SSH repo","fromName":"Breck Yunits","fromEmail":"breck7@gmail.com","sentAt":"2013-09-11T23:19:00Z","receivedAt":"2013-09-11T23:19:00Z","isPatch":false,"sender":{"key":"breck7@gmail.com","avatar":null},"body":"It would be very helpful if you could specify the path to the private\nkey to use for ssh remotes just like in ssh.\n\n```\ngit push origin master -i 'path_to_key'\n```\n\nAlthought there are workarounds involving ssh config, if you have a\nserver that has hundreds of git repos, each with the own private key,\nthose workarounds become unusable.\n\nThis is a very popular request with thousands of comments about it, for example:\n\nhttp://superuser.com/questions/232373/tell-git-which-private-key-to-use\n\nhttp://stackoverflow.com/questions/3496037/how-to-specify-which-ssh-key-to-use-within-git-for-git-push-in-order-to-have-git\n\nThoughts?\n\nThanks!\n\nBreck Yunits\nbreck7@gmail.com\n"},{"id":"227505","messageId":"xmqqeh8ur6uc.fsf@gitster.dls.corp.google.com","threadId":"34910","inReplyTo":"CAOgHByvTtNDho50B+pECMeXkq=3FF8EheFbP4iQbKYTiAPTwYw@mail.gmail.com","subject":"Re: Specifying a private key when connecting to a remote SSH repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-12T04:39:55Z","receivedAt":"2013-09-12T04:39:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Breck Yunits writes:\n\n> It would be very helpful if you could specify the path to the private\n> key to use for ssh remotes just like in ssh.\n\nYou could add a support for the \"remote..sshIdentityFile\"\nconfiguration variable, i.e.\n\n\t[remote \"origin\"]\n\t\turl = breck@example.com:projects/w.git\n sshIdentityFile = ~/.ssh/id_for_example_com\n\nand then teach the codepath that leads to connect.c::git_connect()\nto pass it down, and add \"-o 'IdentityFile %s'\" to the command line\nthat invokes \"ssh\".\n\nBut you would need the same number of configuration as you have\nremotes that need such custom identity files, which happens to be\nthe same number of entries you would normally configure with the\nstandard ~/.ssh/config file, so I do not think it is worth it.\n\nIf the only thing you are interested in supporting is a one-shot\ninvocation, i.e. giving which identity file to use from the command\nline when you run either \"git push\" or \"git fetch\", I suspect that\nyou could play with GIT_SSH environment variable, e.g.\n\n GIT_SSH_IDENTITY_FILE=$HOME/.ssh/id_for_example_com git push\n\nand do something ugly like the attached, I suppose.\n\nIt also crossed my mind that you could (ab)use the credential helper\nframework and ask it to return not the password but the identity\nfilename, and pass it down the callchain to git_connect(), but again\nyou will have to teach the credential helper as many settings as you\nwould need to make in ~/.ssh/config anyway, so I find it dubious how\nit would be a win.\n\n connect.c | 9 ++++++++-\n 1 file changed, 8 insertions(+), 1 deletion(-)\n\ndiff --git a/connect.c b/connect.c\nindex a80ebd3..87b7ceb 100644\n--- a/connect.c\n+++ b/connect.c\n@@ -623,9 +623,10 @@ struct child_process *git_connect(int fd[2], const char *url_orig,\n \t\tdie(\"command line too long\");\n \n \tconn->in = conn->out = -1;\n-\tconn->argv = arg = xcalloc(7, sizeof(*arg));\n+\tconn->argv = arg = xcalloc(20, sizeof(*arg));\n \tif (protocol == PROTO_SSH) {\n \t\tconst char *ssh = getenv(\"GIT_SSH\");\n+\t\tconst char *ssh_ident = getenv(\"GIT_SSH_IDENTITY_FILE\");\n \t\tint putty = ssh && strcasestr(ssh, \"plink\");\n \t\tif (!ssh) ssh = \"ssh\";\n \n@@ -637,6 +638,12 @@ struct child_process *git_connect(int fd[2], const char *url_orig,\n \t\t\t*arg++ = putty ? \"-P\" : \"-p\";\n \t\t\t*arg++ = port;\n \t\t}\n+\t\tif (ssh_ident) {\n+\t\t\tchar *ident_arg = xmalloc(strlen(ssh_ident) + 50);\n+\t\t\tsprintf(ident_arg, \"IdentityFile %s\", ssh_ident);\n+\t\t\t*arg++ = \"-o\";\n+\t\t\t*arg++ = ident_arg;\n+\t\t}\n \t\t*arg++ = host;\n \t}\n \telse {\n"},{"id":"227507","messageId":"20130912051913.GA1977@sigill.intra.peff.net","threadId":"34910","inReplyTo":"xmqqeh8ur6uc.fsf@gitster.dls.corp.google.com","subject":"Re: Specifying a private key when connecting to a remote SSH repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-12T05:19:13Z","receivedAt":"2013-09-12T05:19:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Sep 11, 2013 at 09:39:55PM -0700, Junio C Hamano wrote:\n\n> If the only thing you are interested in supporting is a one-shot\n> invocation, i.e. giving which identity file to use from the command\n> line when you run either \"git push\" or \"git fetch\", I suspect that\n> you could play with GIT_SSH environment variable, e.g.\n> \n> GIT_SSH_IDENTITY_FILE=$HOME/.ssh/id_for_example_com git push\n> \n> and do something ugly like the attached, I suppose.\n\nWe already have GIT_SSH, so I would expect:\n\n GIT_SSH='ssh -i $HOME/.ssh/id_for_example_com' git push\n\nto work. But sadly, GIT_SSH does not use the shell, unlike most other\nconfigure git commands. :(\n\nWe could consider it a consistency bug and fix it, though I suspect we\nmay be annoying people on Windows who have spaces in their paths.\n\nIf we do go the route of adding a new variable, it would make sense to\nadd something for specifying arbitrary arguments, not just the identity\nfile. Something like GIT_SSH_ARGS would be enough, though once you start\nhandling splitting, dequoting, and interpreting variables, you're better\noff using the shell. So maybe GIT_SSH_SHELL or similar as a preferred\nversion of GIT_SSH that uses the shell.\n\n> It also crossed my mind that you could (ab)use the credential helper\n> framework and ask it to return not the password but the identity\n> filename, and pass it down the callchain to git_connect(), but again\n> you will have to teach the credential helper as many settings as you\n> would need to make in ~/.ssh/config anyway, so I find it dubious how\n> it would be a win.\n\nYou could write a credential helper shell script that knows about\nclasses of remotes (e.g., selecting an identity file based on the\nhostname), and write only a few lines to cover a large number of hosts.\nFor example:\n\n #!/bin/sh\n test \"$1\" = \"get\" || exit 0\n while IFS== read key val; do\n test \"$key\" = \"host\" || continue\n case \"$val\" in\n *.example.com) echo sshident=com_key ;;\n *.example.net) echo sshident=net_key ;;\n esac\n done\n\nBut it feels a bit hacky to be using the credential helpers at all for\nssh connections.\n\n-Peff\n"},{"id":"227538","messageId":"xmqq1u4uqc3q.fsf@gitster.dls.corp.google.com","threadId":"34910","inReplyTo":"20130912051913.GA1977@sigill.intra.peff.net","subject":"Re: Specifying a private key when connecting to a remote SSH repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-12T15:43:53Z","receivedAt":"2013-09-12T15:43:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> We already have GIT_SSH, so I would expect:\n>\n> GIT_SSH='ssh -i $HOME/.ssh/id_for_example_com' git push\n>\n> to work. But sadly, GIT_SSH does not use the shell, unlike most other\n> configure git commands. :(\n\nYou read me correctly ;-)\n\n> We could consider it a consistency bug and fix it, though I suspect we\n> may be annoying people on Windows who have spaces in their paths.\n\nAgain, you read me correctly ;-)\n\n> You could write a credential helper shell script that knows about\n> classes of remotes (e.g., selecting an identity file based on the\n> hostname), and write only a few lines to cover a large number of hosts.\n\nYes, but the same trick can be used in $HOME/.ssh/config to let one\nentry cover the same large number of hosts, so...\n\n> For example:\n>\n> #!/bin/sh\n> test \"$1\" = \"get\" || exit 0\n> while IFS== read key val; do\n> test \"$key\" = \"host\" || continue\n> case \"$val\" in\n> *.example.com) echo sshident=com_key ;;\n> *.example.net) echo sshident=net_key ;;\n> esac\n> done\n>\n> But it feels a bit hacky to be using the credential helpers at all for\n> ssh connections.\n\nYeah, perhaps.\n"},{"id":"227545","messageId":"CAOgHBysgqX7cDxuJ_TWL_RFtty60O6gb7LBEvSAfR33HWoAC-w@mail.gmail.com","threadId":"34910","inReplyTo":"xmqq1u4uqc3q.fsf@gitster.dls.corp.google.com","subject":"Re: Specifying a private key when connecting to a remote SSH repo","fromName":"Breck Yunits","fromEmail":"breck7@gmail.com","sentAt":"2013-09-12T17:48:31Z","receivedAt":"2013-09-12T17:48:31Z","isPatch":false,"sender":{"key":"breck7@gmail.com","avatar":null},"body":"Thanks very much for the feedback and implementation suggestions.\n\n> If the only thing you are interested in supporting is a one-shot\n> invocation, i.e. giving which identity file to use from the command\n> line when you run either \"git push\" or \"git fetch\",\n\nYes, this is the new option that could benefit the most people.\n\nI think this workflow would be very fast and make it very easy to have\n1 key per project right where you need it:\n\n```\nmkdir project\ncd project\nssh-keygen -t rsa -N \"\" -f deploy.key\ngit init\necho \"deploy.key*\" > .gitignore\necho \"Hello world\" > readme.md\ngit add .\ngit commit -m \"Initial commit\"\ngit remote add origin git@github.com:breck7/project.git\ngit push -u origin master -ssh \"-i deploy.key\"\n```\n\nThis probably wouldn't be the option used most frequently, but could\nbe a neat option to have for both power users and new users.\n\nFor power users, I could see this being useful if you have many\nprojects that all have different keys.\n\nFor new users, I could see this is as a quick way to \"get out of\ntrouble\" if you are running into ssh problems.\n\n-Breck\n\n\nOn Thu, Sep 12, 2013 at 8:43 AM, Junio C Hamano wrote:\n> Jeff King writes:\n>\n>> We already have GIT_SSH, so I would expect:\n>>\n>> GIT_SSH='ssh -i $HOME/.ssh/id_for_example_com' git push\n>>\n>> to work. But sadly, GIT_SSH does not use the shell, unlike most other\n>> configure git commands. :(\n>\n> You read me correctly ;-)\n>\n>> We could consider it a consistency bug and fix it, though I suspect we\n>> may be annoying people on Windows who have spaces in their paths.\n>\n> Again, you read me correctly ;-)\n>\n>> You could write a credential helper shell script that knows about\n>> classes of remotes (e.g., selecting an identity file based on the\n>> hostname), and write only a few lines to cover a large number of hosts.\n>\n> Yes, but the same trick can be used in $HOME/.ssh/config to let one\n> entry cover the same large number of hosts, so...\n>\n>> For example:\n>>\n>> #!/bin/sh\n>> test \"$1\" = \"get\" || exit 0\n>> while IFS== read key val; do\n>> test \"$key\" = \"host\" || continue\n>> case \"$val\" in\n>> *.example.com) echo sshident=com_key ;;\n>> *.example.net) echo sshident=net_key ;;\n>> esac\n>> done\n>>\n>> But it feels a bit hacky to be using the credential helpers at all for\n>> ssh connections.\n>\n> Yeah, perhaps.\n"}]}