It appears you are set up to deploy to GitHub and as such that requires you to have a GitHub user set so it knows where to deploy to. Depending on your environment you need to set that environment variable before running the command:

export GIT_USER=yourusername

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/sh
exec /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.

In ~/.ssh/config, add:

Host github.com
 HostName github.com
 IdentityFile ~/.ssh/id_rsa_github

If the config file is new, check access permissions using

stat -c %a ~/.ssh/config

if returns NOT 600, you should do

chmod 600 ~/.ssh/config

Now you can do git clone [email protected]:{ORG_NAME}/{REPO_NAME}.git

• Where {ORG_NAME} is your GitHub user account (or organization account)'s GitHub URI name.
  • Note that there is a colon : after github.com instead of the slash / - as this is not a URI.
• And {REPO_NAME} is your GitHub repo's URI name
• For example, for the Linux kernel this would be git clone [email protected]:torvalds/linux.git).

NOTE: On Linux and macOS, verify that the permissions on your IdentityFile are 400. SSH will reject, in a not clearly explicit manner, SSH keys that are too readable. It will just look like a credential rejection. The solution, in this case, is:

chmod 400 ~/.ssh/id_rsa_github

Since my 2013 answer (Git 1.8.3.4), a new configuration has been set: core.sshCommand

If this variable is set, git fetch and git push will use the specified command instead of ssh when they need to connect to a remote system.
The command is in the same form as the GIT_SSH_COMMAND environment variable and is overridden when the environment variable is set.

It has been introduced in Git 2.10, commit 3c8ede3, June 2016

Since then, you have Git 2.13, commit dd33e077, Feb. 2017, which has ssh.variant

Depending on the value of the environment variables GIT_SSH or GIT_SSH_COMMAND, or the config setting core.sshCommand, Git auto-detects whether to adjust its command-line parameters for use with plink or tortoiseplink, as opposed to the default (OpenSSH).

The config variable ssh.variant can be set to override this auto-detection; valid values are ssh, plink, putty or tortoiseplink.
Any other value will be treated as normal ssh. This setting can be overridden via the environment variable GIT_SSH_VARIANT.

For those, I need to use the SSH client that Git for Windows came with

So for the repos where you need ssh instead of putty, you can use both settings to set exactly in your configuration what you want.

 cd /path/to/my/repo
 git config ssh.variant ssh

None of the answers so far worked for me. What ended up fixing this issue for me was removing quotes from my GIT_SSH variable and don't escape any characters at all, no MSYS path style (eg. /c/path\ to\ putty/plink.exe). Just enter the path normally, Git handles the quoting.

set GIT_SSH=C:\path to putty\plink.exe

That's it. When using GIT_TRACE you can see that the variable gets quoted in the resulting command so:

1. the added double quotes change the string passed to the command and

2. the path is wrapped in single quotes so the spaces are ok.

Hope that helps someone.

You don't have to set an environment variable anymore in Windows.

With git 2.10+ (Q3 2016), you also have the possibility to set a config for GIT_SSH_COMMAND, which is easier than an environment variable (and can be set globally, or locally for a specific repo)

See commit 3c8ede3 (26 Jun 2016) by Nguyễn Thái Ngọc Duy (pclouds).
^{(Merged by Junio C Hamano -- gitster -- in commit dc21164, 19 Jul 2016)}

A new configuration variable core.sshCommand has been added to specify what value for GIT_SSH_COMMAND to use per repository.

core.sshCommand:

If this variable is set, git fetch and git push will use the specified command instead of ssh when they need to connect to a remote system.
The command is in the same form as the GIT_SSH_COMMAND environment variable and is overridden when the environment variable is set.

It means the git push can be:

cd /path/to/my/repo
git config core.sshCommand 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no' 
# later on
git push origin master

With Git 2.16 (Q1 2018), you will have a new mechanism to upgrade the wire protocol in place is proposed and demonstrated that it works with the older versions of Git without harming them.

See commit 6464679 (16 Oct 2017), and commit 0cd8328 (26 Sep 2017) by Jonathan Tan (jhowtan).
See commit 94b8ae5, commit 3c88ebd, commit 19113a2, commit 0c2f0d2, commit 2609043, commit aa9bab2, commit dfe422d, commit 373d70e, commit 5d2124b (16 Oct 2017) by Brandon Williams (mbrandonw).
^{(Merged by Junio C Hamano -- gitster -- in commit 4c6dad0, 06 Dec 2017)}

ssh: introduce a 'simple' ssh variant

When using the 'ssh' transport, the '-o' option is used to specify an environment variable which should be set on the remote end.
This allows Git to send additional information when contacting the server, requesting the use of a different protocol version via the 'GIT_PROTOCOL' environment variable like so: "-o SendEnv=GIT_PROTOCOL".

Unfortunately not all ssh variants support the sending of environment variables to the remote end.
To account for this, only use the '-o' option for ssh variants which are OpenSSH compliant.
This is done by checking that the basename of the ssh command is 'ssh' or the ssh variant is overridden to be 'ssh' (via the ssh.variant config).

Other options like '-p' and '-P', which are used to specify a specific port to use, or '-4' and '-6', which are used to indicate that IPV4 or IPV6 addresses should be used, may also not be supported by all ssh variants.

Currently if an ssh command's basename wasn't 'plink' or 'tortoiseplink', Git assumes that the command is an OpenSSH variant.
Since user configured ssh commands may not be OpenSSH compliant, tighten this constraint and assume a variant of 'simple' if the basename of the command doesn't match the variants known to Git.
The new ssh variant 'simple' will only have the host and command to execute ([username@]host command) passed as parameters to the ssh command.

None of these solutions worked for me.

Instead, I elaborate on @Martin v. Löwis's mention of setting a config file for SSH.

SSH will look for the user's ~/.ssh/config file. I have mine setup as:

Host gitserv
    Hostname remote.server.com
    IdentityFile ~/.ssh/id_rsa.github
    IdentitiesOnly yes # see NOTES below
    AddKeysToAgent yes

And I add a remote git repository:

git remote add origin git@gitserv:myrepo.git

(or clone a fresh copy of the repo with git@gitserv:myrepo.git as address)

And then git commands work normally for me.

git push -v origin master

If you have submodules, you can also execute the following in the repo directory, to force the submodules to use the same key:

git config url.git@gitserv:.insteadOf https://remote.server.com

NOTES

• The IdentitiesOnly yes is required to prevent the SSH default behavior of sending the identity file matching the default filename for each protocol. If you have a file named ~/.ssh/id_rsa that will get tried BEFORE your ~/.ssh/id_rsa.github without this option.

• AddKeysToAgent yes lets you avoid reentering the key passphrase every time.

• You can also add User git to avoid writing git@ every time.

References

• Best way to use multiple SSH private keys on one client
• How could I stop ssh offering a wrong key