Re: Specifying a private key when connecting to a remote SSH repo
Thanks very much for the feedback and implementation suggestions. > If the only thing you are interested in supporting is a one-shot > invocation, i.e. giving which identity file to use from the command > line when you run either "git push" or "git fetch", Yes, this is the new option that could benefit the most people. I think this workflow would be very fast and make it very easy to have 1 key per project right where you need it: ``` mkdir project cd project ssh-keygen -t rsa -N "" -f deploy.key git init echo "deploy.key*" > .gitignore echo "Hello world" > readme.md git add . git commit -m "Initial commit" git remote add origin g...@github.com:breck7/project.git git push -u origin master -ssh "-i deploy.key" ``` This probably wouldn't be the option used most frequently, but could be a neat option to have for both power users and new users. For power users, I could see this being useful if you have many projects that all have different keys. For new users, I could see this is as a quick way to "get out of trouble" if you are running into ssh problems. -Breck On Thu, Sep 12, 2013 at 8:43 AM, Junio C Hamano wrote: > Jeff King writes: > >> We already have GIT_SSH, so I would expect: >> >> GIT_SSH='ssh -i $HOME/.ssh/id_for_example_com' git push >> >> to work. But sadly, GIT_SSH does not use the shell, unlike most other >> configure git commands. :( > > You read me correctly ;-) > >> We could consider it a consistency bug and fix it, though I suspect we >> may be annoying people on Windows who have spaces in their paths. > > Again, you read me correctly ;-) > >> You could write a credential helper shell script that knows about >> classes of remotes (e.g., selecting an identity file based on the >> hostname), and write only a few lines to cover a large number of hosts. > > Yes, but the same trick can be used in $HOME/.ssh/config to let one > entry cover the same large number of hosts, so... > >> For example: >> >> #!/bin/sh >> test "$1" = "get" || exit 0 >> while IFS== read key val; do >> test "$key" = "host" || continue >> case "$val" in >> *.example.com) echo sshident=com_key ;; >> *.example.net) echo sshident=net_key ;; >> esac >> done >> >> But it feels a bit hacky to be using the credential helpers at all for >> ssh connections. > > Yeah, perhaps. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Specifying a private key when connecting to a remote SSH repo
Jeff King writes: > We already have GIT_SSH, so I would expect: > > GIT_SSH='ssh -i $HOME/.ssh/id_for_example_com' git push > > to work. But sadly, GIT_SSH does not use the shell, unlike most other > configure git commands. :( You read me correctly ;-) > We could consider it a consistency bug and fix it, though I suspect we > may be annoying people on Windows who have spaces in their paths. Again, you read me correctly ;-) > You could write a credential helper shell script that knows about > classes of remotes (e.g., selecting an identity file based on the > hostname), and write only a few lines to cover a large number of hosts. Yes, but the same trick can be used in $HOME/.ssh/config to let one entry cover the same large number of hosts, so... > For example: > > #!/bin/sh > test "$1" = "get" || exit 0 > while IFS== read key val; do > test "$key" = "host" || continue > case "$val" in > *.example.com) echo sshident=com_key ;; > *.example.net) echo sshident=net_key ;; > esac > done > > But it feels a bit hacky to be using the credential helpers at all for > ssh connections. Yeah, perhaps. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Specifying a private key when connecting to a remote SSH repo
On Wed, Sep 11, 2013 at 09:39:55PM -0700, Junio C Hamano wrote: > If the only thing you are interested in supporting is a one-shot > invocation, i.e. giving which identity file to use from the command > line when you run either "git push" or "git fetch", I suspect that > you could play with GIT_SSH environment variable, e.g. > > GIT_SSH_IDENTITY_FILE=$HOME/.ssh/id_for_example_com git push > > and do something ugly like the attached, I suppose. We already have GIT_SSH, so I would expect: GIT_SSH='ssh -i $HOME/.ssh/id_for_example_com' git push to work. But sadly, GIT_SSH does not use the shell, unlike most other configure git commands. :( We could consider it a consistency bug and fix it, though I suspect we may be annoying people on Windows who have spaces in their paths. If we do go the route of adding a new variable, it would make sense to add something for specifying arbitrary arguments, not just the identity file. Something like GIT_SSH_ARGS would be enough, though once you start handling splitting, dequoting, and interpreting variables, you're better off using the shell. So maybe GIT_SSH_SHELL or similar as a preferred version of GIT_SSH that uses the shell. > It also crossed my mind that you could (ab)use the credential helper > framework and ask it to return not the password but the identity > filename, and pass it down the callchain to git_connect(), but again > you will have to teach the credential helper as many settings as you > would need to make in ~/.ssh/config anyway, so I find it dubious how > it would be a win. You could write a credential helper shell script that knows about classes of remotes (e.g., selecting an identity file based on the hostname), and write only a few lines to cover a large number of hosts. For example: #!/bin/sh test "$1" = "get" || exit 0 while IFS== read key val; do test "$key" = "host" || continue case "$val" in *.example.com) echo sshident=com_key ;; *.example.net) echo sshident=net_key ;; esac done But it feels a bit hacky to be using the credential helpers at all for ssh connections. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Specifying a private key when connecting to a remote SSH repo
Breck Yunits writes: > It would be very helpful if you could specify the path to the private > key to use for ssh remotes just like in ssh. You could add a support for the "remote..sshIdentityFile" configuration variable, i.e. [remote "origin"] url = br...@example.com:projects/w.git sshIdentityFile = ~/.ssh/id_for_example_com and then teach the codepath that leads to connect.c::git_connect() to pass it down, and add "-o 'IdentityFile %s'" to the command line that invokes "ssh". But you would need the same number of configuration as you have remotes that need such custom identity files, which happens to be the same number of entries you would normally configure with the standard ~/.ssh/config file, so I do not think it is worth it. If the only thing you are interested in supporting is a one-shot invocation, i.e. giving which identity file to use from the command line when you run either "git push" or "git fetch", I suspect that you could play with GIT_SSH environment variable, e.g. GIT_SSH_IDENTITY_FILE=$HOME/.ssh/id_for_example_com git push and do something ugly like the attached, I suppose. It also crossed my mind that you could (ab)use the credential helper framework and ask it to return not the password but the identity filename, and pass it down the callchain to git_connect(), but again you will have to teach the credential helper as many settings as you would need to make in ~/.ssh/config anyway, so I find it dubious how it would be a win. connect.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/connect.c b/connect.c index a80ebd3..87b7ceb 100644 --- a/connect.c +++ b/connect.c @@ -623,9 +623,10 @@ struct child_process *git_connect(int fd[2], const char *url_orig, die("command line too long"); conn->in = conn->out = -1; - conn->argv = arg = xcalloc(7, sizeof(*arg)); + conn->argv = arg = xcalloc(20, sizeof(*arg)); if (protocol == PROTO_SSH) { const char *ssh = getenv("GIT_SSH"); + const char *ssh_ident = getenv("GIT_SSH_IDENTITY_FILE"); int putty = ssh && strcasestr(ssh, "plink"); if (!ssh) ssh = "ssh"; @@ -637,6 +638,12 @@ struct child_process *git_connect(int fd[2], const char *url_orig, *arg++ = putty ? "-P" : "-p"; *arg++ = port; } + if (ssh_ident) { + char *ident_arg = xmalloc(strlen(ssh_ident) + 50); + sprintf(ident_arg, "IdentityFile %s", ssh_ident); + *arg++ = "-o"; + *arg++ = ident_arg; + } *arg++ = host; } else { -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Specifying a private key when connecting to a remote SSH repo
It would be very helpful if you could specify the path to the private key to use for ssh remotes just like in ssh. ``` git push origin master -i 'path_to_key' ``` Althought there are workarounds involving ssh config, if you have a server that has hundreds of git repos, each with the own private key, those workarounds become unusable. This is a very popular request with thousands of comments about it, for example: http://superuser.com/questions/232373/tell-git-which-private-key-to-use http://stackoverflow.com/questions/3496037/how-to-specify-which-ssh-key-to-use-within-git-for-git-push-in-order-to-have-git Thoughts? Thanks! Breck Yunits bre...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html