Git clone with custom SSH using GIT_SSH error

You cannot provide options in the GIT_SSH environment variable; from the git man page:

   GIT_SSH       If this environment variable is set then git fetch and git push will use this command instead of ssh when they need to connect       to a remote system. The $GIT_SSH command will be given exactly two arguments: the username@host (or just host) from the URL       and the shell command to execute on that remote system.       To pass options to the program that you want to list in GIT_SSH you will need to wrap the program and options into a shell       script, then set GIT_SSH to refer to the shell script.

One option is to add a stanza to your .ssh/config file with the appropriate configuration:

Host bitbucket.org  StrictHostKeyChecking no  IdentityFile /home/me/my_private_key

Another option is to point GIT_SSH to a shell script that does what you want. E.g., in /home/me/bin/bitbucket_ssh, put:

#!/bin/shexec /usr/bin/ssh -o StrictHostKeyChecking=no -i /home/me/my_private_key "$@"

And then point GIT_SSH at /home/me/bin/bitbucket_ssh.

I prefer using .ssh/config when possible, because this avoids the need to create a per-destination script for each remote.

Note that starting with git 2.3+ (Q1 2015), what you initially tried would work, with the new environment variable GIT_SSH_COMMAND.

See commit 3994276 from Thomas Quinot (quinot):

git_connect: set ssh shell command in GIT_SSH_COMMAND

It may be impractical to install a wrapper script for GIT_SSH when additional parameters need to be passed.
Provide an alternative way of specifying a shell command to be run, including command line arguments, by means of the GIT_SSH_COMMAND environment variable, which behaves like GIT_SSH but is passed to the shell.

The special circuitry to modify parameters in the case of using PuTTY's plink/tortoiseplink is activated only when using GIT_SSH; in the case of using GIT_SSH_COMMAND, it is deliberately left up to the user to make any required parameters adaptation before calling the underlying ssh implementation.

GIT_SSH_COMMAND:

If either of these environment variables is set then 'git fetch' and 'git push' will use the specified command instead of 'ssh' when they need to connect to a remote system.
The command will be given exactly two or four arguments:

• the 'username@host' (or just 'host') from the URL and the shell command to execute on that remote system, optionally preceded by '-p' (literally) and
• the 'port' from the URL when it specifies something other than the default SSH port.

$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).

Building on larsk's answer and VonC's answer, you can create a git_ssh.sh script such as:

#!/bin/sh# Workaround: GIT_SSH_COMMAND isn't supported by Git < 2.3exec ${GIT_SSH_COMMAND:-ssh} "$@"

Then invoke your git command like this:

export GIT_SSH_COMMAND="/usr/bin/ssh -o StrictHostKeyChecking=no -i /home/me/my_private_key"export GIT_SSH=path/to/git_ssh.shgit ...

This is how it works:

In Git v2.3+ $GIT_SSH_COMMAND takes precedence over $GIT_SSH, but older versions don't respect $GIT_SSH_COMMAND at all.

$GIT_SSH can hold only a path to the ssh command on the system. It can't pass extra command line arguments to that command, so how can we pass extra arguments to ssh?

A workaround is to create a script that includes the ssh command and its extra arguments. This is exactly what the git_ssh.sh is all about: Since we already set $GIT_SSH_COMMAND to be /usr/bin/ssh -o StrictHostKeyChecking=no -i /home/me/my_private_key, it is exactly what we need to exec, and the "$@" is here to pass the arguments passed to git_ssh.sh by Git itself to the $GIT_SSH_COMMAND.

The ${...:-ssh} part, while not strictly needed is a nice touch that will make $GIT_SSH_COMMAND default to the ssh command, and thus setting GIT_SSH=git_ssh.sh will not break a normal git execution.

As added value, this script is totally ignored by Git v2.3+, and the $GIT_SSH_COMMAND is used directly in this case.