Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This question already has an answer here:

I want to clone a repo in a non-interactive way. When cloning, git asks to confirm host's fingerprint:

The authenticity of host ' (' can't be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)? no

How do I force "yes" every time this questions pops up? I tried using yes yes | git clone ..., but it doesn't work.

EDIT: Here's a solution: Can I automatically add a new host to known_hosts? (adds entires to known_hosts with ssh-keyscan).

share|improve this question

marked as duplicate by mdpc, womble Dec 23 '15 at 10:55

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

Doesn't bitbucket have access to git via http or https ? Would be strange to not add it, considering the amount of nazi firewalls blocking everything but HTTP. – BatchyX Feb 3 '13 at 9:51
Interesting to see that even after two years this question does not have a proper answer. There are few other cases where git will prompt, for example if you try to clone over http and the server is asking for basic_auth. How to do this in non-interactice mode? – sorin Oct 23 '14 at 12:06
Adding the -q option (quiet) did it for me. Now I'm stuck automating the passphrase. – user295402 Jun 21 '15 at 21:34


As i said previously and somebody edited out, "I don't think that is the best solution, but it was a solution for me. ", in other words: it's surely not the most secure way of sorting things out, so make sure you know what you doing. ( some people have been voting me down even tough i adverted on the first version of the answer )


Adding the domainnames to the known_hosts file using the ssh-keyscan command solved the issue:

ssh-keyscan <> >> ~/.ssh/known_hosts

share|improve this answer
@Falcon Momot, why did you edit my answer? Just to take a smile out and fix the "j" case? haha Are you a bot? – kroe Nov 19 '14 at 14:15
It came up in a review queue. Just minor edits for style. – Falcon Momot Nov 19 '14 at 22:06
cool i did not even knew review queues exists... – kroe Nov 20 '14 at 0:37
Please don't do this way. This is totally NOT secure: fingerprints are not here to annoy you but to make sure you're not facing a man-in-the-middle attack. Please see my answer below. – autra Oct 21 '15 at 12:17
as i said, "I don't think that is the best solution, but was a solution for me." because i was in a rush, surely there is "policataly correct way" of doing it (( : – kroe Oct 21 '15 at 14:05

None of the answer are secure. You have 2 options:

Use https protocol instead of git

It won't ask you for a fingerprint, because ssh is not involved, https (duh) is used instead. If you're using a minimalist image or Docker, you might need to install the ca-certificates package.

If you really want git+ssh protocol

Do you really need to add the key at runtime? This is totally not secure.

Before running your script, get the key from github (on your local machine):

ssh-keyscan >> githubKey

Generate the fingerprint:

ssh-keygen -lf githubKey

And check it manually against those listed in this page (ok, there you trust https certificates and OpenSSL to bring you the original github website, but it's still a lot better than blindly accepting a public key).

Then, you harcode it in your script by adding in it:

echo '<copy paste the content of 'cat githubKey' on your machine>'  >> ~/.ssh/known_hosts

before the git clone.

The GitHub public key will only change if they believe it was compromised (or not secure enough). If this is ever the case, you want your script to fail anyway.

share|improve this answer
This is the only correct and secure answer to the question. Why is it the last one? I'm ashamed of humanity ;-( – Janek Warchoł Oct 17 '15 at 17:10
You can't do non-interactive HTTPS with GitHub if you use two factor auth, unfortunately. – Brett Widmeier Apr 13 at 13:17
I don't see why not. We are talking about a public repo here, no need for authentication. Cloning a private repo from a script is another thing entirely: you need to authorize your script to do so. – autra Apr 20 at 10:44

While I certainly understand that you want to automate such a process, doing so would be ill-advised. The reason why SSH and related networking subcomponents balk when using a secure protocol is to WARN a human that a system's public key is unknown. This is intentional - the user needs to explicitly inform the system the host is expected. You wouldn't want to auto accept every public key presented to you or part of the security in SSH or TLS/SSL could be compromised. One example is via a man-in-the-middle attack such as when a proxy software presents it's own key in the place of a host you expect.

Proceed with caution.

If you have no fear about the source of the code across the wire, you should explicitly and exclusively use the git:// protocol when cloning - it's authenticationless and in clear text.

share|improve this answer
I can definitively see use cases where we need to enforce non-interactive uses of git clone... and that doesn't mean we require to accept any check (the fingerprint one in particular). In my case, I would be perfectly glad to fail automatically on such thing. – vaab Apr 11 '14 at 11:04

I believe a better option here is to back up and empty your ~/.ssh/known_hosts file, manually perform the SSH connection, verifying the IP address and fingerprint, mv ~/.ssh/known_hosts ~/bitbucket_hosts, then use the contents of ~/bitbucket_hostsin your script to automatically append the known fingerprints to the known_hosts file (don't forget to restore the original ~/.ssh/known_hosts).

This step only needs to be performed once (on any machine, I believe), and once you have the fingerprints, you can incorporate it in to your automation script.

share|improve this answer

As Jeff Hall said, doing so is dangerous as it allows undetected man-in-the-middle attacks. However, you could use the StrictHostKeyChecking no option in ssh to disable checking the host keys. However, I'd be very careful with that option if I were you.

share|improve this answer
It also allows man-in-the-middle right? – autra Jun 25 '15 at 15:37

One nice option is to temporarily answer yes for the RSA fingerprint check on a specific clone:

yes | git clone

Edit: Doesn't work anymore. Tests now fail for me on fedora 19 with git 1.9.3:

$ yes | git clone
Cloning into 'django-csv-tool'...
The authenticity of host ' (' can't be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)? 
share|improve this answer
did not work for me with github git@ address – kroe Oct 31 '14 at 4:51
@kroe error message? write access on the repo? – hobs Oct 31 '14 at 23:49
my bad, i did not post the error code. – kroe Nov 2 '14 at 4:12
Does not work for me, still stuck on Are you sure you want to continue connecting (yes/no)? – Greg Jan 9 '15 at 17:34
Doesn't work for me anymore either. Will edit. My test environment must've been flawed. ssh-keyscan from @kroe is still your best option. – hobs Jan 9 '15 at 19:17

Adding the key to .ssh/known_hosts appears to be the right thing to do.

Though when you automate the task you want to make sure the key is not already contained and added on each clone/pull tasks.

This snippet will only add the fingerprint if not already found:

if [ ! -n "$(grep "^ " ~/.ssh/known_hosts)" ]; then ssh-keyscan >> ~/.ssh/known_hosts 2>/dev/null; fi
share|improve this answer
This was perfect. Can easily be put into a deploy script and is safer than disabling host verification. Here's a one-liner for github: if [ ! -n "$(grep "^ " ~/.ssh/known_hosts)" ]; then ssh-keyscan >> ~/.ssh/known_hosts 2>/dev/null; fi; ssh-agent bash -c "ssh-add /path/to/your/deploy/id_rsa; git clone -b master /your/target/dir – tweak2 Oct 14 '15 at 20:54
This does not work when HashKnownHosts is enabled in /etc/ssh/ssh_config (or ~/.ssh/config). Instead of [ ! -n "$(grep "^ " ~/.ssh/known_hosts)" ] it would be better to use [ ! "$(ssh-keygen -F" ], which finds both hashed and non-hashed lines in known_hosts. – Claus Conrad Apr 22 at 17:23

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