Using GIT_SSH_COMMAND in Git for Windows

Question

I'm using Fourth release candidate of Git for Windows 2.x now, and using GIT_SSH_COMMAND in shell to avoid SSH's host verification. In Git Bash I write something like this:

$ GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" git push origin master

How can I do something like this in Windows cmd? Can't find any answers anywhere.

Answer 1

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.

Answer 2

Here is the answer:

set GIT_SSH_COMMAND=ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no & git push origin master

Answer 3

There's a better way to achieve your goal. While the question and various answers are interesting and instructive, the best way to achieve the goal does not involve the GIT_SSH_COMMAND variable.

Instead of putting the information in "git", put the information into "ssh".

The "ssh" command has always had a "config" file in Unix/Linux. That capability is available in Windows, also, at least in recent years. Configure "ssh" to know about your identity file, and then when you go to perform the "git clone" command...

git clone <repository>

...specify the <repository> in the style of ssh protocol. Here is the ssh protocol style, as described on the "git" reference page for "git clone", at the sub-header "GIT URLs":

[user@]host.xz:path/to/repo.git/

Note that there is no scheme specifier; which is to say there is no indication of ssh: nor git: nor https: nor ftps:. Instead, the colon : is separating "host" from "path". This use of the colon : does not conform to URL format, and the non-conformance distinguishes this protocol style from the others.

A potentially important benefit of doing the configuration within "ssh" is that "ssh" allows alias names. Suppose, for "ssh" sessions to a particular machine, I normally want to login as myself, but sometimes I want to login as somebody else, named "user_for_git". Further suppose that the identity files for the users are different. The following "config" for "ssh" has entries that are named by the real domain for myself, but with an alias for the "user_for_git". Note that the keyword "Host" introduces a section, while the variable "HostName" is one of several parameters within the section.

Host go_git.example.com
    # Specify the real host name
    HostName    = example.com
    User        = user_for_git
    IdentityFile    = ~/.ssh/id_rsa_for_git_at_example_com

Host example.com
    # Specify the real host name
    HostName    = example.com
    User        = user_me
    IdentityFile    = ~/.ssh/id_rsa_for_normal

With that in place, the "git clone" command can be as follows:

git clone go_git.example.host:/path/to/repo.git

Note that in this case the optional user@ portion of the syntax is not used. The remote repository is specified by just host : path, but in this case the host is an alias defined in the "ssh" config file.

In Linux/Unix, the "ssh" config file is named config and is in the hidden directory .ssh, which is located under the home directory $HOME; this is expressed as ~/.ssh/config. For the equivalent location(s) within Windows, check the answers here: https://stackoverflow.com/a/62842368/3552393