git/list[1] front-page[2] threads[3] people[4] search[5] about
 

RE: [BUG] GIT_SSH_COMMAND is not being decomposed

From
Randall S. Becker <rsbecker@nexbridge.com>
Date
Apr 15, 2019, 19:20 UTC
Message-ID
<004d01d4f3c0$3ff358d0$bfda0a70$@nexbridge.com>
In-Reply-To
<20190413214736.GD15936@szeder.dev>
On April 13, 2019 17:48, SZEDER Gábor wrote:
Show 77 quoted lines
> On Sat, Apr 13, 2019 at 10:39:35PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > On Sat, Apr 13 2019, Randall S. Becker wrote:
> >
> > > I am encountering a problem on one of our NonStop platform variants
> > > where the GIT_SSH_COMMAND string is not being broken into
> > > constituent parts. This is causing SSH to not run properly. As
> > > background, SSH is not in a standard location and has non-standard
> > > required arguments. This also occurs with core.sshCommand. The
> situation is:
> > >
> > > git config --global core.sshCommand '/G/system/zssh/sshossz5 -Q'
> > >
> > > which correctly sets .gitconfig as:
> > >
> > > [core]
> > >         sshCommand = /G/system/zssh/sshossz5 -Q
> > >
> > > When git is run with GIT_TRACE=true GIT_PACKET_TRACE=true git fetch
> > >
> > > We get the partial trace:
> > > 14:19:56.027088 trace: built-in: git fetch
> > > 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5 -Q' -G
> > > user@host
> > >
> > > The same trace on our systems that actually do work results in:
> > > 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5' '-Q'
> > > -G user@host
> > >
> > > I need help resolving why this is happening (as in where to look and
> > > debug the situation).
> >
> > This doesn't seem to be documented *explicitly* (except between the
> > lines & inferred), but it's only supported to pass a *command* there,
> > i.e. the path of the ssh binary.
> 
> 'man git' it quite explicit about this:
> 
>   $GIT_SSH_COMMAND takes precedence over $GIT_SSH, and is interpreted
>   by the shell, which allows additional arguments to be included.
>   $GIT_SSH on the other hand must be just the path to a program (which
>   can be a wrapper shell script, if additional arguments are needed).
> 
> Quick test shows that the implementation agrees with the
> documentation:
> 
>   $ GIT_TRACE=2 GIT_SSH_COMMAND='/usr/bin/ssh -v' git push -n github
>   23:39:02.048870 git.c:419               trace: built-in: git push -n github
>   23:39:02.060821 run-command.c:643       trace: run_command: unset
> GIT_PREFIX; '/usr/bin/ssh -v' git@github.com 'git-receive-pack
> '\''/szeder/git'\'''
>   OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g  1 Mar 2016
>   debug1: Reading configuration data /home/szeder/.ssh/config
>   <... snipt rest of the verbose ssh output ...>
> 
> And the config setting works, too:
> 
>   $ GIT_TRACE=2 git -c core.sshCommand='/usr/bin/ssh -v' push -n github
>   23:42:55.277776 git.c:439               trace: built-in: git push -n github
>   23:42:55.285149 run-command.c:663       trace: run_command: unset
> GIT_CONFIG_PARAMETERS GIT_PREFIX; '/usr/bin/ssh -v' git@github.com
> 'git-receive-pack '\''/szeder/git'\'''
>   OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g  1 Mar 2016
>   debug1: Reading configuration data /home/szeder/.ssh/config
>   <...>
> 
> Note that in both cases the trace shows '/usr/bin/ssh -v', IOW neither
> $GIT_SSH_COMMAND nor 'core.sshCommand' are broken up.
> 
> But this is just an avarage Linux box, so perhaps this is a NonStop-specific
> issue?
> 
> 
> > See the code around get_ssh_command()
> > in connect.c. The whole env/config value we look up gets passed as one.
> >
> > So if you need arguments you need to create a wrapper script and set
> > ssh command to that script.
What is strange is that GIT_SSH_COMMAND='/usr/bin/ssh -v' should not execute if we are just looking at an object path. It should be broken into '/usr/bin/ssh' and '-v' otherwise spawn* or exec* will not execute it. I'm still trying to understand why I can successfully do things like the following:
$ GIT_SSH_COMMAND="ssh -i ~/.ssh/myid" git fetch
on virtually any platform at my disposal (Windows, Ubuntu, MacOS, the older NonStop variant), and have that work with no problem. Somewhere after get_ssh_command(), the command is being interpreted it its parts either as a shell or something else (still trying to find that).
Previous: Randall S. BeckerNext: Andreas Schwab
Message 6 of 10 in “[BUG] GIT_SSH_COMMAND is not being decomposed”
  1. Randall S. BeckerApr 13, 2019
  2. Ævar Arnfjörð BjarmasonApr 13, 2019
  3. Randall S. BeckerApr 13, 2019
  4. SZEDER GáborApr 13, 2019
  5. Randall S. BeckerApr 14, 2019
  6. Randall S. BeckerApr 15, 2019
  7. Andreas SchwabApr 15, 2019
  8. Randall S. BeckerApr 15, 2019
  9. Junio C HamanoApr 16, 2019
  10. Johannes SixtApr 15, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.