158

I'm trying to run git clone without ssh checking the repository host's key. I can do it from ssh like that:

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@host

Is there any way to pass the same ssh options to the git clone command?

Edit: There is a restriction that I can't modify ~/.ssh/config or any other files on that machine.

2
  • 4
    What you try to do is very risky and you probably shouldn't do it. Disabling the verification if the remote SSH server's identity is a bad idea in most situations. You effectively disable all security gained through using SSH and open yourself up to man-in-the-middle attacks.
    – aef
    Commented Jul 31, 2017 at 1:25
  • 5
    Actually, this is often exactly what you want to do. You have an internal repo. If someone has managed to spoof that, then you are in trouble. It is not "very risky" at all. In fact how often do you do an out-of-band check of the host key? (You ought to). Commented Oct 17, 2018 at 11:24

8 Answers 8

247

The recently released git 2.3 supports a new variable "GIT_SSH_COMMAND" which can be used to define a command WITH parameters.

GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" git clone user@host

$GIT_SSH_COMMAND takes precedence over $GIT_SSH, and is interpreted by the shell, which allows additional arguments to be included.

Edit: While this answers the exact question that was asked I would agree with the edit that Poyoman suggested to better use this option that was added in the last decade instead.

GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=accept-new" git clone user@host
4
  • Should there be new line before git clone or is the code correct? Commented Aug 4, 2016 at 14:29
  • 12
    This should be correct, without the newline the variable should be set for the following command. If you add a newline, you would need to export the variable, then it should also work.
    – Boris
    Commented Aug 5, 2016 at 8:19
  • it will not work with git 1.9 version I believe, is there any alternate solution for git 1.9
    – Anupam
    Commented Aug 6, 2020 at 17:42
  • 2
    This is especially useful for initial git clone when one uses different SSH keys for repos hosted on same remote git server, ie. in situation when ssh_config options HostName and User won't distinguish cloning different repos.
    – Jiri B
    Commented Mar 22, 2021 at 20:11
51

Another option made to specify different keys is git config core.sshCommand with git 2.10 + (Q3 2016).

This is an alternative to the environment variable described in Boris's answer)

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.

Similar to $GIT_ASKPASS or $GIT_PROXY_COMMAND, we also read from config file first then fall back to $GIT_SSH_COMMAND.

This is useful for selecting different private keys targetting the same host (e.g. github)

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 clone can be:

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

If you want to apply that for all repos, as user1300959 adds in the comments, you would use a global configuration.

git config --global core.sshCommand 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'
3
  • 5
    More likely you don't have a repo yet, since you do git clone - in this case you may want to configure the git ssh command globally: git config --global core.sshCommand ...
    – iurii
    Commented Feb 22, 2017 at 15:51
  • @user1300959 Good point, thank you. I have included your comment in the answer for more visibility.
    – VonC
    Commented Feb 22, 2017 at 16:40
  • 1
    This is the best answer. Commented Aug 26, 2018 at 22:41
49

Add them to your ~/.ssh/config:

Host host
    HostName host
    User user
    SshOption1 Value1
    SshOption2 Value2

The Host entry is what you’ll specify on the command line, and the HostName is the true hostname. They can be the same, or the Host entry can be an alias. The User entry is used if you do not specify user@ on the command line.

If you must configure this on the command line, set the GIT_SSH environment variable to point to a script with your options in it.

2
  • 5
    I forgot to say that I can't modify any files on that machine. Otherwise, yeah your solution would work.
    – Daniel
    Commented Oct 14, 2011 at 20:02
  • 30
    Use the GIT_SSH environment variable.
    – Josh Lee
    Commented Oct 14, 2011 at 21:41
36

Repository level configuration without impacting the system level settings

Consolidating the already available answers, I am choosing the below steps. This ensures that the configuration changes do not impact at the machine level, but just for the repository being worked on. This is needed in my case as my script needs to be executed on a shared Bamboo agent.

  1. Clone the repository taking the GIT_SSH_COMMAND approach.

    GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" git clone ssh://url
    
  2. Once cloned, navigate into repository directory.

    cd repo-dir
    
  3. Set core.sshCommand configuration so that all future calls can be just run with git commands like usual, but internally consuming the provided git options.

    git config core.sshCommand 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'
    
0
23

Here is tricky example how to pass the ssh arguments by using GIT_SSH variable:

$ echo 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no $*' > ssh
$ chmod +x ssh
$ GIT_TRACE=1 GIT_SSH="$PWD/ssh" git clone user@host

Note: Above lines are terminal command-lines which you should paste into your terminal. It'll create a file ssh, make it executable and executes it.

If you'd like to pass the private key option, please check How to tell git which private key to use?.

2
  • Nice! Question: Both $* and "$@" seem to work. Normally I use "$@", since the other one seems deprecated. Is there a reason to prefer $* in this case?
    – mh8020
    Commented Jun 24, 2020 at 12:15
  • 1
    @mh8020 They are expanded differently when you have multiple arguments and/or your arguments contain spaces. You are right to use "$@", it is usually the correct choice. See unix.stackexchange.com/a/41595/10822 Commented Nov 10, 2020 at 10:34
7

I think that update git to an version >= 2.3 and use GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" git clone user@host is the bet option, but if it not possible, @josh-lee gave a good option, but please, update your answer indenting the ssh config file.

Host host
    HostName host
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
7

A safer way is:

git config --global core.sshCommand 'ssh -o StrictHostKeyChecking=accept-new'

This is safer than StrictHostKeyChecking=no because accept-new will still produce an error for keys that it knows have changed, just not for keys it has never seen before. no disables all checking.

For a one-off command use:

git -c core.sshCommand='ssh -o StrictHostKeyChecking=accept-new' clone ...
0

This issue has been fixed by doing follow step's in Window machine:-

  • Create config file under C:\Users\username.ssh folder.

  • add the following line to a config file.

    host <HOST>
    hostname <HOSTNAME>
    user <USER_NAME>
    IdentityFile ~/.ssh/id_rsa
    IdentitiesOnly yes
    port <PORT_NUMBER>
    KexAlgorithms +diffie-hellman-group1-sha1
    
  • then try again.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.