Git error: “Host Key Verification Failed” when connecting to remote repository












118














I am trying to connect to a remote Git repository that resides on my web server and clone it to my machine.



I am using the following format for my command:



git clone ssh://username@domain.com/repository.git


This has worked fine for most of my team members. Usually after running this command Git will prompt for the user's password, and then run the cloning. However, when running on one of my machines I get the following error:




Host key verification failed.



fatal: Could not read from remote
repository.




We are not using SSH keys to connect to this repository, so I'm not sure why Git is checking for one on this particular machine.










share|improve this question






















  • You would need to configure https hosting of this repo, just like it is done on GitHub and Bitbucket.
    – IgorGanapolsky
    Nov 16 '16 at 15:11
















118














I am trying to connect to a remote Git repository that resides on my web server and clone it to my machine.



I am using the following format for my command:



git clone ssh://username@domain.com/repository.git


This has worked fine for most of my team members. Usually after running this command Git will prompt for the user's password, and then run the cloning. However, when running on one of my machines I get the following error:




Host key verification failed.



fatal: Could not read from remote
repository.




We are not using SSH keys to connect to this repository, so I'm not sure why Git is checking for one on this particular machine.










share|improve this question






















  • You would need to configure https hosting of this repo, just like it is done on GitHub and Bitbucket.
    – IgorGanapolsky
    Nov 16 '16 at 15:11














118












118








118


35





I am trying to connect to a remote Git repository that resides on my web server and clone it to my machine.



I am using the following format for my command:



git clone ssh://username@domain.com/repository.git


This has worked fine for most of my team members. Usually after running this command Git will prompt for the user's password, and then run the cloning. However, when running on one of my machines I get the following error:




Host key verification failed.



fatal: Could not read from remote
repository.




We are not using SSH keys to connect to this repository, so I'm not sure why Git is checking for one on this particular machine.










share|improve this question













I am trying to connect to a remote Git repository that resides on my web server and clone it to my machine.



I am using the following format for my command:



git clone ssh://username@domain.com/repository.git


This has worked fine for most of my team members. Usually after running this command Git will prompt for the user's password, and then run the cloning. However, when running on one of my machines I get the following error:




Host key verification failed.



fatal: Could not read from remote
repository.




We are not using SSH keys to connect to this repository, so I'm not sure why Git is checking for one on this particular machine.







git ssh ssh-keys






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 13 '12 at 15:26









bootsz

696264




696264












  • You would need to configure https hosting of this repo, just like it is done on GitHub and Bitbucket.
    – IgorGanapolsky
    Nov 16 '16 at 15:11


















  • You would need to configure https hosting of this repo, just like it is done on GitHub and Bitbucket.
    – IgorGanapolsky
    Nov 16 '16 at 15:11
















You would need to configure https hosting of this repo, just like it is done on GitHub and Bitbucket.
– IgorGanapolsky
Nov 16 '16 at 15:11




You would need to configure https hosting of this repo, just like it is done on GitHub and Bitbucket.
– IgorGanapolsky
Nov 16 '16 at 15:11












14 Answers
14






active

oldest

votes


















70














You are connecting via the SSH protocol. Using SSH, every host has a key. Clients remember the host key associated with a particular address and refuse to connect if a host key appears to change. This prevents man in the middle attacks.



The host key for domain.com has changed. If this does not seem fishy to you, you can remove the old key from your local cache using



$ ssh-keygen -R domain.com


I strongly encourage you to consider having users authenticate with keys as well. That way, ssh-agent can store key material for convenience (rather than everyone having to enter her password for each connection to the server), and passwords do not go over the network.






share|improve this answer

















  • 8




    Or you could remove the offending line manually from ~/.ssh/known_hosts
    – ZaMoose
    Nov 13 '12 at 16:16






  • 5




    @ZaMoose If ~/.ssh/known_hosts is hashed, it won’t be obvious.
    – Greg Bacon
    Nov 13 '12 at 16:28






  • 2




    @GregBacon It's hashed, but the url isn't, so just find the line that starts with the desired domain and remove the line. That's always been how I did it when I pointed old subdomains to a new ssh server and needed to clear out the old server's host key.
    – Stephen Smith
    Jul 8 '14 at 2:46










  • This doesn't fix the problem - it just removes the old known hosts - right?
    – alex
    Feb 12 at 19:19






  • 1




    @alex Depends on your config. This removes the old host key and will fix the issue if the client will allow the user to accept a new host key. In locked-down systems, a trusted user will have to update the host key — likely in /etc/ssh and not under ~/.ssh.
    – Greg Bacon
    Feb 13 at 15:51



















210














As I answered previously in Cloning git repo causes error - Host key verification failed. fatal: The remote end hung up unexpectedly, add the GitHub to the list of authorized hosts:



ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts






share|improve this answer



















  • 2




    This is the most secure way, short of already having the key present. That's assuming you only run it once, not every time you connect to the server.
    – Zenexer
    Aug 13 '15 at 13:49












  • My company's private fit repository is using ecdsa as key, so if the solution isn't working, maybe it is because the algorithm isn't correct
    – Fendy
    Apr 12 '16 at 3:07






  • 4




    This should be the accepted answer. Thanks for saving my day.
    – Keyur K
    Aug 9 '17 at 13:11










  • worked for me too, I was wondering why I couldn't clone my own repo
    – StackAttack
    Nov 16 at 16:34



















30














I had the similar issue, but, using SSH keys. From Tupy's answer, above, I figured out that the issue is with known_hosts file not being present or github.com not being present in the list of known hosts. Here are the steps I followed to resolve it -




  1. mkdir -p ~/.ssh


  2. ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts


  3. ssh-keygen -t rsa -C "user.email"

  4. Add the id_rsa.pub key to SSH keys list on your GitHub profile.






share|improve this answer



















  • 3




    It should be known_hosts.
    – jcoffland
    Oct 15 '15 at 20:39










  • You could replace 1 & 2 with simply touch ~/.ssh/known_hosts.
    – OJFord
    Mar 21 at 12:18










  • @OJFord FYI: I have edited the original answer in a way that makes your comment obsolete. TBH and with all due respect it wasn't entirely correct in the first place. The touch command would fail in case ~/.ssh directory does not exist, so step 1 was still required. Also you don't need to touch the file before using >> redirection. It will be created if necessary (but just the file, not entire path, so still mkdir -p is needed). The -p option make it work in case the directory already exists.
    – Tadeusz Łazurski
    Jun 10 at 17:14



















15














This is happening because github is not currently in your known hosts.



You should be prompted to add github to your known hosts. If this hasn't happened, you can run ssh -T git@github.com to receive the prompt again.






share|improve this answer























  • This is the right answer if you never get prompted.
    – Matt Hagemann
    Jul 7 at 8:23



















9














For me, I just had to type "yes" at the prompt which asks "Are you sure you want to continue connecting (yes/no)?" rather than just pressing Enter.






share|improve this answer





















  • This answer lead me to realize I had to manually clone my repo on my build server in order to type 'yes' and get my bitbucket server added to my known_hosts
    – Sashah
    Nov 20 '17 at 20:34






  • 1




    @Sashah If all you need is the bitbucket server in known_hosts, you can edit the file manually. No need to clone the repo if this is the only reason to do so.
    – Code-Apprentice
    Dec 13 '17 at 16:03








  • 2




    hahaha thanks for this!
    – khakiout
    Feb 17 at 2:44



















7














I got the same problem on a newly installed system, but this was a udev problem. There was no /dev/tty node, so I had to do:



mknod -m 666 /dev/tty c 5 0





share|improve this answer

















  • 1




    It worked for me because /dev/tty was created as a file, very odd! (so you have to remove it then recreate it with mknod)
    – Doomsday
    Nov 2 '14 at 14:31










  • @Geoffroy , I removed /dev/tty and now when do sudo , I face this error : sudo: sorry, you must have a tty to run sudo
    – Milad
    Dec 17 '14 at 12:29










  • @xe4me I never said you should remove it, depending on the system it is actually required. Reboot should fix it.
    – Geoffroy
    Dec 17 '14 at 17:33










  • @Geoffroy , actually the first commentator , said I have to remove and the recreate :d Nope , rebooting didn't work , I had to tell the root , he fixed it :d
    – Milad
    Dec 18 '14 at 9:58



















4














If you are in office intranet (otherwise dangerous) which is always protected by firewalls simply have the following lines in your ~/.ssh/config



Host *

StrictHostKeyChecking no

UserKnownHostsFile=/dev/null






share|improve this answer

















  • 1




    This is still dangerous, with our without corporate firewalls. How do you know you're talking to the real github without verifying the server key?
    – Mnebuerquo
    Mar 17 at 20:42










  • In corporate environments local git repos are mostly used, never opensource one. Worst case .ssh config at the top of the file can have github explicit host related config lines for ssh to choose more specific matches.
    – sunil
    May 21 at 13:36



















3














What worked for me was to first add my SSH key of the new computer, I followed these instructions from GitLab - add SSH key. Note that since I'm on Win10, I had to do all these commands in Git Bash on Windows (it didn't work in regular DOS cmd Shell).



Then again in Git Bash, I had to do a git clone of the repo that I had problems with, and in my case I had to clone it to a different name since I already had it locally and didn't want to lose my commits. For example



git clone ssh://git@gitServerUrl/myRepo.git myRepo2


Then I got the prompt to add it to known hosts list, the question might be this one:




Are you sure you want to continue connecting (yes/no)?




I typed "yes" and it finally worked, you should typically get a message similar to this:




Warning: Permanently added '[your repo link]' (ECDSA) to the list of known hosts.




Note: if you are on Windows, make sure that you use Git Bash for all the commands, this did not work in regular cmd shell or powershell, I really had to do this in Git Bash.



Lastly I deleted the second clone repo (myRepo2 in the example) and went back to my first repo and I could finally do all the Git stuff like normal in my favorite editor VSCode.






share|improve this answer





















  • Indeed, my Cygwin prompt looks nearly exactly like my git bash prompt, but it only works in the git bash prompt!
    – Josiah Yoder
    Aug 2 at 18:00



















2














If you are using git for Windows.




  • Open the git GUI.

  • Open the local git repository in git GUI.

  • Add the remote or push if the remote already exists.

  • Answer "yes" to the question about whether you want to continue.


The GUI client adds the key for you to ~/.ssh/known_hosts. This is easier to remember if you don't do it often and also avoids the need to use the git command line (the standard Windows command lines don't have the ssh-keyscan executable.






share|improve this answer





























    1














    Its means your remote host key was changed (May be host password change),



    Your terminal suggested to execute this command as root user



    $ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]


    You have to remove that host name from hosts list on your pc/server. Copy that suggested command and execute as a root user.



    $ sudo su                                                        // Login as a root user

    $ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net] // Terminal suggested command execute here
    Host [www.website.net]:4231 found: line 16 type ECDSA
    /root/.ssh/known_hosts updated.
    Original contents retained as /root/.ssh/known_hosts.old

    $ exit // Exist from root user


    Try Again, Hope this works.






    share|improve this answer





















    • Note: depending on your shell, you may have to escape the square brackets [ and ] or use quotes.
      – Phlarx
      Jan 16 '17 at 19:38





















    0














    I had the similar issue, unfortunately I used the GitExtensions HMI and forgot that I wrote a passphrase.
    With HMI.... forget it ! Do not enter passphrase when you generate your key !






    share|improve this answer





























      0














      You can use your "git url" in 'https" URL format in the Jenkinsfile or wherever you want.



      git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'






      share|improve this answer





























        0














        I got this message when I tried to git clone a repo that was not mine. The fix was to fork and then clone.






        share|improve this answer





























          0














          I was facing the same error inside DockerFile during build time while the image was public. I did little modification in Dockerfile.



           RUN git clone  https://github.com/kacole2/express-node-mongo-skeleton.git /www/nodejs



          This would be because using the git@github.com:... syntax ends up > using SSH to clone, and inside the container, your private key is not > available. You'll want to use RUN git clone > https://github.com/edenhill/librdkafka.git instead.







          share|improve this answer





















            Your Answer






            StackExchange.ifUsing("editor", function () {
            StackExchange.using("externalEditor", function () {
            StackExchange.using("snippets", function () {
            StackExchange.snippets.init();
            });
            });
            }, "code-snippets");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "1"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f13363553%2fgit-error-host-key-verification-failed-when-connecting-to-remote-repository%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            14 Answers
            14






            active

            oldest

            votes








            14 Answers
            14






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            70














            You are connecting via the SSH protocol. Using SSH, every host has a key. Clients remember the host key associated with a particular address and refuse to connect if a host key appears to change. This prevents man in the middle attacks.



            The host key for domain.com has changed. If this does not seem fishy to you, you can remove the old key from your local cache using



            $ ssh-keygen -R domain.com


            I strongly encourage you to consider having users authenticate with keys as well. That way, ssh-agent can store key material for convenience (rather than everyone having to enter her password for each connection to the server), and passwords do not go over the network.






            share|improve this answer

















            • 8




              Or you could remove the offending line manually from ~/.ssh/known_hosts
              – ZaMoose
              Nov 13 '12 at 16:16






            • 5




              @ZaMoose If ~/.ssh/known_hosts is hashed, it won’t be obvious.
              – Greg Bacon
              Nov 13 '12 at 16:28






            • 2




              @GregBacon It's hashed, but the url isn't, so just find the line that starts with the desired domain and remove the line. That's always been how I did it when I pointed old subdomains to a new ssh server and needed to clear out the old server's host key.
              – Stephen Smith
              Jul 8 '14 at 2:46










            • This doesn't fix the problem - it just removes the old known hosts - right?
              – alex
              Feb 12 at 19:19






            • 1




              @alex Depends on your config. This removes the old host key and will fix the issue if the client will allow the user to accept a new host key. In locked-down systems, a trusted user will have to update the host key — likely in /etc/ssh and not under ~/.ssh.
              – Greg Bacon
              Feb 13 at 15:51
















            70














            You are connecting via the SSH protocol. Using SSH, every host has a key. Clients remember the host key associated with a particular address and refuse to connect if a host key appears to change. This prevents man in the middle attacks.



            The host key for domain.com has changed. If this does not seem fishy to you, you can remove the old key from your local cache using



            $ ssh-keygen -R domain.com


            I strongly encourage you to consider having users authenticate with keys as well. That way, ssh-agent can store key material for convenience (rather than everyone having to enter her password for each connection to the server), and passwords do not go over the network.






            share|improve this answer

















            • 8




              Or you could remove the offending line manually from ~/.ssh/known_hosts
              – ZaMoose
              Nov 13 '12 at 16:16






            • 5




              @ZaMoose If ~/.ssh/known_hosts is hashed, it won’t be obvious.
              – Greg Bacon
              Nov 13 '12 at 16:28






            • 2




              @GregBacon It's hashed, but the url isn't, so just find the line that starts with the desired domain and remove the line. That's always been how I did it when I pointed old subdomains to a new ssh server and needed to clear out the old server's host key.
              – Stephen Smith
              Jul 8 '14 at 2:46










            • This doesn't fix the problem - it just removes the old known hosts - right?
              – alex
              Feb 12 at 19:19






            • 1




              @alex Depends on your config. This removes the old host key and will fix the issue if the client will allow the user to accept a new host key. In locked-down systems, a trusted user will have to update the host key — likely in /etc/ssh and not under ~/.ssh.
              – Greg Bacon
              Feb 13 at 15:51














            70












            70








            70






            You are connecting via the SSH protocol. Using SSH, every host has a key. Clients remember the host key associated with a particular address and refuse to connect if a host key appears to change. This prevents man in the middle attacks.



            The host key for domain.com has changed. If this does not seem fishy to you, you can remove the old key from your local cache using



            $ ssh-keygen -R domain.com


            I strongly encourage you to consider having users authenticate with keys as well. That way, ssh-agent can store key material for convenience (rather than everyone having to enter her password for each connection to the server), and passwords do not go over the network.






            share|improve this answer












            You are connecting via the SSH protocol. Using SSH, every host has a key. Clients remember the host key associated with a particular address and refuse to connect if a host key appears to change. This prevents man in the middle attacks.



            The host key for domain.com has changed. If this does not seem fishy to you, you can remove the old key from your local cache using



            $ ssh-keygen -R domain.com


            I strongly encourage you to consider having users authenticate with keys as well. That way, ssh-agent can store key material for convenience (rather than everyone having to enter her password for each connection to the server), and passwords do not go over the network.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Nov 13 '12 at 15:59









            Greg Bacon

            99.2k25161214




            99.2k25161214








            • 8




              Or you could remove the offending line manually from ~/.ssh/known_hosts
              – ZaMoose
              Nov 13 '12 at 16:16






            • 5




              @ZaMoose If ~/.ssh/known_hosts is hashed, it won’t be obvious.
              – Greg Bacon
              Nov 13 '12 at 16:28






            • 2




              @GregBacon It's hashed, but the url isn't, so just find the line that starts with the desired domain and remove the line. That's always been how I did it when I pointed old subdomains to a new ssh server and needed to clear out the old server's host key.
              – Stephen Smith
              Jul 8 '14 at 2:46










            • This doesn't fix the problem - it just removes the old known hosts - right?
              – alex
              Feb 12 at 19:19






            • 1




              @alex Depends on your config. This removes the old host key and will fix the issue if the client will allow the user to accept a new host key. In locked-down systems, a trusted user will have to update the host key — likely in /etc/ssh and not under ~/.ssh.
              – Greg Bacon
              Feb 13 at 15:51














            • 8




              Or you could remove the offending line manually from ~/.ssh/known_hosts
              – ZaMoose
              Nov 13 '12 at 16:16






            • 5




              @ZaMoose If ~/.ssh/known_hosts is hashed, it won’t be obvious.
              – Greg Bacon
              Nov 13 '12 at 16:28






            • 2




              @GregBacon It's hashed, but the url isn't, so just find the line that starts with the desired domain and remove the line. That's always been how I did it when I pointed old subdomains to a new ssh server and needed to clear out the old server's host key.
              – Stephen Smith
              Jul 8 '14 at 2:46










            • This doesn't fix the problem - it just removes the old known hosts - right?
              – alex
              Feb 12 at 19:19






            • 1




              @alex Depends on your config. This removes the old host key and will fix the issue if the client will allow the user to accept a new host key. In locked-down systems, a trusted user will have to update the host key — likely in /etc/ssh and not under ~/.ssh.
              – Greg Bacon
              Feb 13 at 15:51








            8




            8




            Or you could remove the offending line manually from ~/.ssh/known_hosts
            – ZaMoose
            Nov 13 '12 at 16:16




            Or you could remove the offending line manually from ~/.ssh/known_hosts
            – ZaMoose
            Nov 13 '12 at 16:16




            5




            5




            @ZaMoose If ~/.ssh/known_hosts is hashed, it won’t be obvious.
            – Greg Bacon
            Nov 13 '12 at 16:28




            @ZaMoose If ~/.ssh/known_hosts is hashed, it won’t be obvious.
            – Greg Bacon
            Nov 13 '12 at 16:28




            2




            2




            @GregBacon It's hashed, but the url isn't, so just find the line that starts with the desired domain and remove the line. That's always been how I did it when I pointed old subdomains to a new ssh server and needed to clear out the old server's host key.
            – Stephen Smith
            Jul 8 '14 at 2:46




            @GregBacon It's hashed, but the url isn't, so just find the line that starts with the desired domain and remove the line. That's always been how I did it when I pointed old subdomains to a new ssh server and needed to clear out the old server's host key.
            – Stephen Smith
            Jul 8 '14 at 2:46












            This doesn't fix the problem - it just removes the old known hosts - right?
            – alex
            Feb 12 at 19:19




            This doesn't fix the problem - it just removes the old known hosts - right?
            – alex
            Feb 12 at 19:19




            1




            1




            @alex Depends on your config. This removes the old host key and will fix the issue if the client will allow the user to accept a new host key. In locked-down systems, a trusted user will have to update the host key — likely in /etc/ssh and not under ~/.ssh.
            – Greg Bacon
            Feb 13 at 15:51




            @alex Depends on your config. This removes the old host key and will fix the issue if the client will allow the user to accept a new host key. In locked-down systems, a trusted user will have to update the host key — likely in /etc/ssh and not under ~/.ssh.
            – Greg Bacon
            Feb 13 at 15:51













            210














            As I answered previously in Cloning git repo causes error - Host key verification failed. fatal: The remote end hung up unexpectedly, add the GitHub to the list of authorized hosts:



            ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts






            share|improve this answer



















            • 2




              This is the most secure way, short of already having the key present. That's assuming you only run it once, not every time you connect to the server.
              – Zenexer
              Aug 13 '15 at 13:49












            • My company's private fit repository is using ecdsa as key, so if the solution isn't working, maybe it is because the algorithm isn't correct
              – Fendy
              Apr 12 '16 at 3:07






            • 4




              This should be the accepted answer. Thanks for saving my day.
              – Keyur K
              Aug 9 '17 at 13:11










            • worked for me too, I was wondering why I couldn't clone my own repo
              – StackAttack
              Nov 16 at 16:34
















            210














            As I answered previously in Cloning git repo causes error - Host key verification failed. fatal: The remote end hung up unexpectedly, add the GitHub to the list of authorized hosts:



            ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts






            share|improve this answer



















            • 2




              This is the most secure way, short of already having the key present. That's assuming you only run it once, not every time you connect to the server.
              – Zenexer
              Aug 13 '15 at 13:49












            • My company's private fit repository is using ecdsa as key, so if the solution isn't working, maybe it is because the algorithm isn't correct
              – Fendy
              Apr 12 '16 at 3:07






            • 4




              This should be the accepted answer. Thanks for saving my day.
              – Keyur K
              Aug 9 '17 at 13:11










            • worked for me too, I was wondering why I couldn't clone my own repo
              – StackAttack
              Nov 16 at 16:34














            210












            210








            210






            As I answered previously in Cloning git repo causes error - Host key verification failed. fatal: The remote end hung up unexpectedly, add the GitHub to the list of authorized hosts:



            ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts






            share|improve this answer














            As I answered previously in Cloning git repo causes error - Host key verification failed. fatal: The remote end hung up unexpectedly, add the GitHub to the list of authorized hosts:



            ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited May 23 '17 at 12:18









            Community

            11




            11










            answered Apr 1 '15 at 0:17









            Tupy

            3,3974119




            3,3974119








            • 2




              This is the most secure way, short of already having the key present. That's assuming you only run it once, not every time you connect to the server.
              – Zenexer
              Aug 13 '15 at 13:49












            • My company's private fit repository is using ecdsa as key, so if the solution isn't working, maybe it is because the algorithm isn't correct
              – Fendy
              Apr 12 '16 at 3:07






            • 4




              This should be the accepted answer. Thanks for saving my day.
              – Keyur K
              Aug 9 '17 at 13:11










            • worked for me too, I was wondering why I couldn't clone my own repo
              – StackAttack
              Nov 16 at 16:34














            • 2




              This is the most secure way, short of already having the key present. That's assuming you only run it once, not every time you connect to the server.
              – Zenexer
              Aug 13 '15 at 13:49












            • My company's private fit repository is using ecdsa as key, so if the solution isn't working, maybe it is because the algorithm isn't correct
              – Fendy
              Apr 12 '16 at 3:07






            • 4




              This should be the accepted answer. Thanks for saving my day.
              – Keyur K
              Aug 9 '17 at 13:11










            • worked for me too, I was wondering why I couldn't clone my own repo
              – StackAttack
              Nov 16 at 16:34








            2




            2




            This is the most secure way, short of already having the key present. That's assuming you only run it once, not every time you connect to the server.
            – Zenexer
            Aug 13 '15 at 13:49






            This is the most secure way, short of already having the key present. That's assuming you only run it once, not every time you connect to the server.
            – Zenexer
            Aug 13 '15 at 13:49














            My company's private fit repository is using ecdsa as key, so if the solution isn't working, maybe it is because the algorithm isn't correct
            – Fendy
            Apr 12 '16 at 3:07




            My company's private fit repository is using ecdsa as key, so if the solution isn't working, maybe it is because the algorithm isn't correct
            – Fendy
            Apr 12 '16 at 3:07




            4




            4




            This should be the accepted answer. Thanks for saving my day.
            – Keyur K
            Aug 9 '17 at 13:11




            This should be the accepted answer. Thanks for saving my day.
            – Keyur K
            Aug 9 '17 at 13:11












            worked for me too, I was wondering why I couldn't clone my own repo
            – StackAttack
            Nov 16 at 16:34




            worked for me too, I was wondering why I couldn't clone my own repo
            – StackAttack
            Nov 16 at 16:34











            30














            I had the similar issue, but, using SSH keys. From Tupy's answer, above, I figured out that the issue is with known_hosts file not being present or github.com not being present in the list of known hosts. Here are the steps I followed to resolve it -




            1. mkdir -p ~/.ssh


            2. ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts


            3. ssh-keygen -t rsa -C "user.email"

            4. Add the id_rsa.pub key to SSH keys list on your GitHub profile.






            share|improve this answer



















            • 3




              It should be known_hosts.
              – jcoffland
              Oct 15 '15 at 20:39










            • You could replace 1 & 2 with simply touch ~/.ssh/known_hosts.
              – OJFord
              Mar 21 at 12:18










            • @OJFord FYI: I have edited the original answer in a way that makes your comment obsolete. TBH and with all due respect it wasn't entirely correct in the first place. The touch command would fail in case ~/.ssh directory does not exist, so step 1 was still required. Also you don't need to touch the file before using >> redirection. It will be created if necessary (but just the file, not entire path, so still mkdir -p is needed). The -p option make it work in case the directory already exists.
              – Tadeusz Łazurski
              Jun 10 at 17:14
















            30














            I had the similar issue, but, using SSH keys. From Tupy's answer, above, I figured out that the issue is with known_hosts file not being present or github.com not being present in the list of known hosts. Here are the steps I followed to resolve it -




            1. mkdir -p ~/.ssh


            2. ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts


            3. ssh-keygen -t rsa -C "user.email"

            4. Add the id_rsa.pub key to SSH keys list on your GitHub profile.






            share|improve this answer



















            • 3




              It should be known_hosts.
              – jcoffland
              Oct 15 '15 at 20:39










            • You could replace 1 & 2 with simply touch ~/.ssh/known_hosts.
              – OJFord
              Mar 21 at 12:18










            • @OJFord FYI: I have edited the original answer in a way that makes your comment obsolete. TBH and with all due respect it wasn't entirely correct in the first place. The touch command would fail in case ~/.ssh directory does not exist, so step 1 was still required. Also you don't need to touch the file before using >> redirection. It will be created if necessary (but just the file, not entire path, so still mkdir -p is needed). The -p option make it work in case the directory already exists.
              – Tadeusz Łazurski
              Jun 10 at 17:14














            30












            30








            30






            I had the similar issue, but, using SSH keys. From Tupy's answer, above, I figured out that the issue is with known_hosts file not being present or github.com not being present in the list of known hosts. Here are the steps I followed to resolve it -




            1. mkdir -p ~/.ssh


            2. ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts


            3. ssh-keygen -t rsa -C "user.email"

            4. Add the id_rsa.pub key to SSH keys list on your GitHub profile.






            share|improve this answer














            I had the similar issue, but, using SSH keys. From Tupy's answer, above, I figured out that the issue is with known_hosts file not being present or github.com not being present in the list of known hosts. Here are the steps I followed to resolve it -




            1. mkdir -p ~/.ssh


            2. ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts


            3. ssh-keygen -t rsa -C "user.email"

            4. Add the id_rsa.pub key to SSH keys list on your GitHub profile.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jun 10 at 13:43









            Tadeusz Łazurski

            1,2531824




            1,2531824










            answered Apr 28 '15 at 0:16









            Saran

            41748




            41748








            • 3




              It should be known_hosts.
              – jcoffland
              Oct 15 '15 at 20:39










            • You could replace 1 & 2 with simply touch ~/.ssh/known_hosts.
              – OJFord
              Mar 21 at 12:18










            • @OJFord FYI: I have edited the original answer in a way that makes your comment obsolete. TBH and with all due respect it wasn't entirely correct in the first place. The touch command would fail in case ~/.ssh directory does not exist, so step 1 was still required. Also you don't need to touch the file before using >> redirection. It will be created if necessary (but just the file, not entire path, so still mkdir -p is needed). The -p option make it work in case the directory already exists.
              – Tadeusz Łazurski
              Jun 10 at 17:14














            • 3




              It should be known_hosts.
              – jcoffland
              Oct 15 '15 at 20:39










            • You could replace 1 & 2 with simply touch ~/.ssh/known_hosts.
              – OJFord
              Mar 21 at 12:18










            • @OJFord FYI: I have edited the original answer in a way that makes your comment obsolete. TBH and with all due respect it wasn't entirely correct in the first place. The touch command would fail in case ~/.ssh directory does not exist, so step 1 was still required. Also you don't need to touch the file before using >> redirection. It will be created if necessary (but just the file, not entire path, so still mkdir -p is needed). The -p option make it work in case the directory already exists.
              – Tadeusz Łazurski
              Jun 10 at 17:14








            3




            3




            It should be known_hosts.
            – jcoffland
            Oct 15 '15 at 20:39




            It should be known_hosts.
            – jcoffland
            Oct 15 '15 at 20:39












            You could replace 1 & 2 with simply touch ~/.ssh/known_hosts.
            – OJFord
            Mar 21 at 12:18




            You could replace 1 & 2 with simply touch ~/.ssh/known_hosts.
            – OJFord
            Mar 21 at 12:18












            @OJFord FYI: I have edited the original answer in a way that makes your comment obsolete. TBH and with all due respect it wasn't entirely correct in the first place. The touch command would fail in case ~/.ssh directory does not exist, so step 1 was still required. Also you don't need to touch the file before using >> redirection. It will be created if necessary (but just the file, not entire path, so still mkdir -p is needed). The -p option make it work in case the directory already exists.
            – Tadeusz Łazurski
            Jun 10 at 17:14




            @OJFord FYI: I have edited the original answer in a way that makes your comment obsolete. TBH and with all due respect it wasn't entirely correct in the first place. The touch command would fail in case ~/.ssh directory does not exist, so step 1 was still required. Also you don't need to touch the file before using >> redirection. It will be created if necessary (but just the file, not entire path, so still mkdir -p is needed). The -p option make it work in case the directory already exists.
            – Tadeusz Łazurski
            Jun 10 at 17:14











            15














            This is happening because github is not currently in your known hosts.



            You should be prompted to add github to your known hosts. If this hasn't happened, you can run ssh -T git@github.com to receive the prompt again.






            share|improve this answer























            • This is the right answer if you never get prompted.
              – Matt Hagemann
              Jul 7 at 8:23
















            15














            This is happening because github is not currently in your known hosts.



            You should be prompted to add github to your known hosts. If this hasn't happened, you can run ssh -T git@github.com to receive the prompt again.






            share|improve this answer























            • This is the right answer if you never get prompted.
              – Matt Hagemann
              Jul 7 at 8:23














            15












            15








            15






            This is happening because github is not currently in your known hosts.



            You should be prompted to add github to your known hosts. If this hasn't happened, you can run ssh -T git@github.com to receive the prompt again.






            share|improve this answer














            This is happening because github is not currently in your known hosts.



            You should be prompted to add github to your known hosts. If this hasn't happened, you can run ssh -T git@github.com to receive the prompt again.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jul 11 at 9:55

























            answered Nov 1 '17 at 9:46









            Powderham

            20128




            20128












            • This is the right answer if you never get prompted.
              – Matt Hagemann
              Jul 7 at 8:23


















            • This is the right answer if you never get prompted.
              – Matt Hagemann
              Jul 7 at 8:23
















            This is the right answer if you never get prompted.
            – Matt Hagemann
            Jul 7 at 8:23




            This is the right answer if you never get prompted.
            – Matt Hagemann
            Jul 7 at 8:23











            9














            For me, I just had to type "yes" at the prompt which asks "Are you sure you want to continue connecting (yes/no)?" rather than just pressing Enter.






            share|improve this answer





















            • This answer lead me to realize I had to manually clone my repo on my build server in order to type 'yes' and get my bitbucket server added to my known_hosts
              – Sashah
              Nov 20 '17 at 20:34






            • 1




              @Sashah If all you need is the bitbucket server in known_hosts, you can edit the file manually. No need to clone the repo if this is the only reason to do so.
              – Code-Apprentice
              Dec 13 '17 at 16:03








            • 2




              hahaha thanks for this!
              – khakiout
              Feb 17 at 2:44
















            9














            For me, I just had to type "yes" at the prompt which asks "Are you sure you want to continue connecting (yes/no)?" rather than just pressing Enter.






            share|improve this answer





















            • This answer lead me to realize I had to manually clone my repo on my build server in order to type 'yes' and get my bitbucket server added to my known_hosts
              – Sashah
              Nov 20 '17 at 20:34






            • 1




              @Sashah If all you need is the bitbucket server in known_hosts, you can edit the file manually. No need to clone the repo if this is the only reason to do so.
              – Code-Apprentice
              Dec 13 '17 at 16:03








            • 2




              hahaha thanks for this!
              – khakiout
              Feb 17 at 2:44














            9












            9








            9






            For me, I just had to type "yes" at the prompt which asks "Are you sure you want to continue connecting (yes/no)?" rather than just pressing Enter.






            share|improve this answer












            For me, I just had to type "yes" at the prompt which asks "Are you sure you want to continue connecting (yes/no)?" rather than just pressing Enter.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Aug 2 '17 at 22:51









            Code-Apprentice

            46.6k1489168




            46.6k1489168












            • This answer lead me to realize I had to manually clone my repo on my build server in order to type 'yes' and get my bitbucket server added to my known_hosts
              – Sashah
              Nov 20 '17 at 20:34






            • 1




              @Sashah If all you need is the bitbucket server in known_hosts, you can edit the file manually. No need to clone the repo if this is the only reason to do so.
              – Code-Apprentice
              Dec 13 '17 at 16:03








            • 2




              hahaha thanks for this!
              – khakiout
              Feb 17 at 2:44


















            • This answer lead me to realize I had to manually clone my repo on my build server in order to type 'yes' and get my bitbucket server added to my known_hosts
              – Sashah
              Nov 20 '17 at 20:34






            • 1




              @Sashah If all you need is the bitbucket server in known_hosts, you can edit the file manually. No need to clone the repo if this is the only reason to do so.
              – Code-Apprentice
              Dec 13 '17 at 16:03








            • 2




              hahaha thanks for this!
              – khakiout
              Feb 17 at 2:44
















            This answer lead me to realize I had to manually clone my repo on my build server in order to type 'yes' and get my bitbucket server added to my known_hosts
            – Sashah
            Nov 20 '17 at 20:34




            This answer lead me to realize I had to manually clone my repo on my build server in order to type 'yes' and get my bitbucket server added to my known_hosts
            – Sashah
            Nov 20 '17 at 20:34




            1




            1




            @Sashah If all you need is the bitbucket server in known_hosts, you can edit the file manually. No need to clone the repo if this is the only reason to do so.
            – Code-Apprentice
            Dec 13 '17 at 16:03






            @Sashah If all you need is the bitbucket server in known_hosts, you can edit the file manually. No need to clone the repo if this is the only reason to do so.
            – Code-Apprentice
            Dec 13 '17 at 16:03






            2




            2




            hahaha thanks for this!
            – khakiout
            Feb 17 at 2:44




            hahaha thanks for this!
            – khakiout
            Feb 17 at 2:44











            7














            I got the same problem on a newly installed system, but this was a udev problem. There was no /dev/tty node, so I had to do:



            mknod -m 666 /dev/tty c 5 0





            share|improve this answer

















            • 1




              It worked for me because /dev/tty was created as a file, very odd! (so you have to remove it then recreate it with mknod)
              – Doomsday
              Nov 2 '14 at 14:31










            • @Geoffroy , I removed /dev/tty and now when do sudo , I face this error : sudo: sorry, you must have a tty to run sudo
              – Milad
              Dec 17 '14 at 12:29










            • @xe4me I never said you should remove it, depending on the system it is actually required. Reboot should fix it.
              – Geoffroy
              Dec 17 '14 at 17:33










            • @Geoffroy , actually the first commentator , said I have to remove and the recreate :d Nope , rebooting didn't work , I had to tell the root , he fixed it :d
              – Milad
              Dec 18 '14 at 9:58
















            7














            I got the same problem on a newly installed system, but this was a udev problem. There was no /dev/tty node, so I had to do:



            mknod -m 666 /dev/tty c 5 0





            share|improve this answer

















            • 1




              It worked for me because /dev/tty was created as a file, very odd! (so you have to remove it then recreate it with mknod)
              – Doomsday
              Nov 2 '14 at 14:31










            • @Geoffroy , I removed /dev/tty and now when do sudo , I face this error : sudo: sorry, you must have a tty to run sudo
              – Milad
              Dec 17 '14 at 12:29










            • @xe4me I never said you should remove it, depending on the system it is actually required. Reboot should fix it.
              – Geoffroy
              Dec 17 '14 at 17:33










            • @Geoffroy , actually the first commentator , said I have to remove and the recreate :d Nope , rebooting didn't work , I had to tell the root , he fixed it :d
              – Milad
              Dec 18 '14 at 9:58














            7












            7








            7






            I got the same problem on a newly installed system, but this was a udev problem. There was no /dev/tty node, so I had to do:



            mknod -m 666 /dev/tty c 5 0





            share|improve this answer












            I got the same problem on a newly installed system, but this was a udev problem. There was no /dev/tty node, so I had to do:



            mknod -m 666 /dev/tty c 5 0






            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Aug 6 '13 at 12:04









            Geoffroy

            9,06033283




            9,06033283








            • 1




              It worked for me because /dev/tty was created as a file, very odd! (so you have to remove it then recreate it with mknod)
              – Doomsday
              Nov 2 '14 at 14:31










            • @Geoffroy , I removed /dev/tty and now when do sudo , I face this error : sudo: sorry, you must have a tty to run sudo
              – Milad
              Dec 17 '14 at 12:29










            • @xe4me I never said you should remove it, depending on the system it is actually required. Reboot should fix it.
              – Geoffroy
              Dec 17 '14 at 17:33










            • @Geoffroy , actually the first commentator , said I have to remove and the recreate :d Nope , rebooting didn't work , I had to tell the root , he fixed it :d
              – Milad
              Dec 18 '14 at 9:58














            • 1




              It worked for me because /dev/tty was created as a file, very odd! (so you have to remove it then recreate it with mknod)
              – Doomsday
              Nov 2 '14 at 14:31










            • @Geoffroy , I removed /dev/tty and now when do sudo , I face this error : sudo: sorry, you must have a tty to run sudo
              – Milad
              Dec 17 '14 at 12:29










            • @xe4me I never said you should remove it, depending on the system it is actually required. Reboot should fix it.
              – Geoffroy
              Dec 17 '14 at 17:33










            • @Geoffroy , actually the first commentator , said I have to remove and the recreate :d Nope , rebooting didn't work , I had to tell the root , he fixed it :d
              – Milad
              Dec 18 '14 at 9:58








            1




            1




            It worked for me because /dev/tty was created as a file, very odd! (so you have to remove it then recreate it with mknod)
            – Doomsday
            Nov 2 '14 at 14:31




            It worked for me because /dev/tty was created as a file, very odd! (so you have to remove it then recreate it with mknod)
            – Doomsday
            Nov 2 '14 at 14:31












            @Geoffroy , I removed /dev/tty and now when do sudo , I face this error : sudo: sorry, you must have a tty to run sudo
            – Milad
            Dec 17 '14 at 12:29




            @Geoffroy , I removed /dev/tty and now when do sudo , I face this error : sudo: sorry, you must have a tty to run sudo
            – Milad
            Dec 17 '14 at 12:29












            @xe4me I never said you should remove it, depending on the system it is actually required. Reboot should fix it.
            – Geoffroy
            Dec 17 '14 at 17:33




            @xe4me I never said you should remove it, depending on the system it is actually required. Reboot should fix it.
            – Geoffroy
            Dec 17 '14 at 17:33












            @Geoffroy , actually the first commentator , said I have to remove and the recreate :d Nope , rebooting didn't work , I had to tell the root , he fixed it :d
            – Milad
            Dec 18 '14 at 9:58




            @Geoffroy , actually the first commentator , said I have to remove and the recreate :d Nope , rebooting didn't work , I had to tell the root , he fixed it :d
            – Milad
            Dec 18 '14 at 9:58











            4














            If you are in office intranet (otherwise dangerous) which is always protected by firewalls simply have the following lines in your ~/.ssh/config



            Host *

            StrictHostKeyChecking no

            UserKnownHostsFile=/dev/null






            share|improve this answer

















            • 1




              This is still dangerous, with our without corporate firewalls. How do you know you're talking to the real github without verifying the server key?
              – Mnebuerquo
              Mar 17 at 20:42










            • In corporate environments local git repos are mostly used, never opensource one. Worst case .ssh config at the top of the file can have github explicit host related config lines for ssh to choose more specific matches.
              – sunil
              May 21 at 13:36
















            4














            If you are in office intranet (otherwise dangerous) which is always protected by firewalls simply have the following lines in your ~/.ssh/config



            Host *

            StrictHostKeyChecking no

            UserKnownHostsFile=/dev/null






            share|improve this answer

















            • 1




              This is still dangerous, with our without corporate firewalls. How do you know you're talking to the real github without verifying the server key?
              – Mnebuerquo
              Mar 17 at 20:42










            • In corporate environments local git repos are mostly used, never opensource one. Worst case .ssh config at the top of the file can have github explicit host related config lines for ssh to choose more specific matches.
              – sunil
              May 21 at 13:36














            4












            4








            4






            If you are in office intranet (otherwise dangerous) which is always protected by firewalls simply have the following lines in your ~/.ssh/config



            Host *

            StrictHostKeyChecking no

            UserKnownHostsFile=/dev/null






            share|improve this answer












            If you are in office intranet (otherwise dangerous) which is always protected by firewalls simply have the following lines in your ~/.ssh/config



            Host *

            StrictHostKeyChecking no

            UserKnownHostsFile=/dev/null







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Mar 4 '17 at 1:40









            sunil

            14317




            14317








            • 1




              This is still dangerous, with our without corporate firewalls. How do you know you're talking to the real github without verifying the server key?
              – Mnebuerquo
              Mar 17 at 20:42










            • In corporate environments local git repos are mostly used, never opensource one. Worst case .ssh config at the top of the file can have github explicit host related config lines for ssh to choose more specific matches.
              – sunil
              May 21 at 13:36














            • 1




              This is still dangerous, with our without corporate firewalls. How do you know you're talking to the real github without verifying the server key?
              – Mnebuerquo
              Mar 17 at 20:42










            • In corporate environments local git repos are mostly used, never opensource one. Worst case .ssh config at the top of the file can have github explicit host related config lines for ssh to choose more specific matches.
              – sunil
              May 21 at 13:36








            1




            1




            This is still dangerous, with our without corporate firewalls. How do you know you're talking to the real github without verifying the server key?
            – Mnebuerquo
            Mar 17 at 20:42




            This is still dangerous, with our without corporate firewalls. How do you know you're talking to the real github without verifying the server key?
            – Mnebuerquo
            Mar 17 at 20:42












            In corporate environments local git repos are mostly used, never opensource one. Worst case .ssh config at the top of the file can have github explicit host related config lines for ssh to choose more specific matches.
            – sunil
            May 21 at 13:36




            In corporate environments local git repos are mostly used, never opensource one. Worst case .ssh config at the top of the file can have github explicit host related config lines for ssh to choose more specific matches.
            – sunil
            May 21 at 13:36











            3














            What worked for me was to first add my SSH key of the new computer, I followed these instructions from GitLab - add SSH key. Note that since I'm on Win10, I had to do all these commands in Git Bash on Windows (it didn't work in regular DOS cmd Shell).



            Then again in Git Bash, I had to do a git clone of the repo that I had problems with, and in my case I had to clone it to a different name since I already had it locally and didn't want to lose my commits. For example



            git clone ssh://git@gitServerUrl/myRepo.git myRepo2


            Then I got the prompt to add it to known hosts list, the question might be this one:




            Are you sure you want to continue connecting (yes/no)?




            I typed "yes" and it finally worked, you should typically get a message similar to this:




            Warning: Permanently added '[your repo link]' (ECDSA) to the list of known hosts.




            Note: if you are on Windows, make sure that you use Git Bash for all the commands, this did not work in regular cmd shell or powershell, I really had to do this in Git Bash.



            Lastly I deleted the second clone repo (myRepo2 in the example) and went back to my first repo and I could finally do all the Git stuff like normal in my favorite editor VSCode.






            share|improve this answer





















            • Indeed, my Cygwin prompt looks nearly exactly like my git bash prompt, but it only works in the git bash prompt!
              – Josiah Yoder
              Aug 2 at 18:00
















            3














            What worked for me was to first add my SSH key of the new computer, I followed these instructions from GitLab - add SSH key. Note that since I'm on Win10, I had to do all these commands in Git Bash on Windows (it didn't work in regular DOS cmd Shell).



            Then again in Git Bash, I had to do a git clone of the repo that I had problems with, and in my case I had to clone it to a different name since I already had it locally and didn't want to lose my commits. For example



            git clone ssh://git@gitServerUrl/myRepo.git myRepo2


            Then I got the prompt to add it to known hosts list, the question might be this one:




            Are you sure you want to continue connecting (yes/no)?




            I typed "yes" and it finally worked, you should typically get a message similar to this:




            Warning: Permanently added '[your repo link]' (ECDSA) to the list of known hosts.




            Note: if you are on Windows, make sure that you use Git Bash for all the commands, this did not work in regular cmd shell or powershell, I really had to do this in Git Bash.



            Lastly I deleted the second clone repo (myRepo2 in the example) and went back to my first repo and I could finally do all the Git stuff like normal in my favorite editor VSCode.






            share|improve this answer





















            • Indeed, my Cygwin prompt looks nearly exactly like my git bash prompt, but it only works in the git bash prompt!
              – Josiah Yoder
              Aug 2 at 18:00














            3












            3








            3






            What worked for me was to first add my SSH key of the new computer, I followed these instructions from GitLab - add SSH key. Note that since I'm on Win10, I had to do all these commands in Git Bash on Windows (it didn't work in regular DOS cmd Shell).



            Then again in Git Bash, I had to do a git clone of the repo that I had problems with, and in my case I had to clone it to a different name since I already had it locally and didn't want to lose my commits. For example



            git clone ssh://git@gitServerUrl/myRepo.git myRepo2


            Then I got the prompt to add it to known hosts list, the question might be this one:




            Are you sure you want to continue connecting (yes/no)?




            I typed "yes" and it finally worked, you should typically get a message similar to this:




            Warning: Permanently added '[your repo link]' (ECDSA) to the list of known hosts.




            Note: if you are on Windows, make sure that you use Git Bash for all the commands, this did not work in regular cmd shell or powershell, I really had to do this in Git Bash.



            Lastly I deleted the second clone repo (myRepo2 in the example) and went back to my first repo and I could finally do all the Git stuff like normal in my favorite editor VSCode.






            share|improve this answer












            What worked for me was to first add my SSH key of the new computer, I followed these instructions from GitLab - add SSH key. Note that since I'm on Win10, I had to do all these commands in Git Bash on Windows (it didn't work in regular DOS cmd Shell).



            Then again in Git Bash, I had to do a git clone of the repo that I had problems with, and in my case I had to clone it to a different name since I already had it locally and didn't want to lose my commits. For example



            git clone ssh://git@gitServerUrl/myRepo.git myRepo2


            Then I got the prompt to add it to known hosts list, the question might be this one:




            Are you sure you want to continue connecting (yes/no)?




            I typed "yes" and it finally worked, you should typically get a message similar to this:




            Warning: Permanently added '[your repo link]' (ECDSA) to the list of known hosts.




            Note: if you are on Windows, make sure that you use Git Bash for all the commands, this did not work in regular cmd shell or powershell, I really had to do this in Git Bash.



            Lastly I deleted the second clone repo (myRepo2 in the example) and went back to my first repo and I could finally do all the Git stuff like normal in my favorite editor VSCode.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Jan 21 at 21:18









            ghiscoding

            4,42234177




            4,42234177












            • Indeed, my Cygwin prompt looks nearly exactly like my git bash prompt, but it only works in the git bash prompt!
              – Josiah Yoder
              Aug 2 at 18:00


















            • Indeed, my Cygwin prompt looks nearly exactly like my git bash prompt, but it only works in the git bash prompt!
              – Josiah Yoder
              Aug 2 at 18:00
















            Indeed, my Cygwin prompt looks nearly exactly like my git bash prompt, but it only works in the git bash prompt!
            – Josiah Yoder
            Aug 2 at 18:00




            Indeed, my Cygwin prompt looks nearly exactly like my git bash prompt, but it only works in the git bash prompt!
            – Josiah Yoder
            Aug 2 at 18:00











            2














            If you are using git for Windows.




            • Open the git GUI.

            • Open the local git repository in git GUI.

            • Add the remote or push if the remote already exists.

            • Answer "yes" to the question about whether you want to continue.


            The GUI client adds the key for you to ~/.ssh/known_hosts. This is easier to remember if you don't do it often and also avoids the need to use the git command line (the standard Windows command lines don't have the ssh-keyscan executable.






            share|improve this answer


























              2














              If you are using git for Windows.




              • Open the git GUI.

              • Open the local git repository in git GUI.

              • Add the remote or push if the remote already exists.

              • Answer "yes" to the question about whether you want to continue.


              The GUI client adds the key for you to ~/.ssh/known_hosts. This is easier to remember if you don't do it often and also avoids the need to use the git command line (the standard Windows command lines don't have the ssh-keyscan executable.






              share|improve this answer
























                2












                2








                2






                If you are using git for Windows.




                • Open the git GUI.

                • Open the local git repository in git GUI.

                • Add the remote or push if the remote already exists.

                • Answer "yes" to the question about whether you want to continue.


                The GUI client adds the key for you to ~/.ssh/known_hosts. This is easier to remember if you don't do it often and also avoids the need to use the git command line (the standard Windows command lines don't have the ssh-keyscan executable.






                share|improve this answer












                If you are using git for Windows.




                • Open the git GUI.

                • Open the local git repository in git GUI.

                • Add the remote or push if the remote already exists.

                • Answer "yes" to the question about whether you want to continue.


                The GUI client adds the key for you to ~/.ssh/known_hosts. This is easier to remember if you don't do it often and also avoids the need to use the git command line (the standard Windows command lines don't have the ssh-keyscan executable.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Apr 5 at 16:51









                Julian Knight

                3,86111630




                3,86111630























                    1














                    Its means your remote host key was changed (May be host password change),



                    Your terminal suggested to execute this command as root user



                    $ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]


                    You have to remove that host name from hosts list on your pc/server. Copy that suggested command and execute as a root user.



                    $ sudo su                                                        // Login as a root user

                    $ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net] // Terminal suggested command execute here
                    Host [www.website.net]:4231 found: line 16 type ECDSA
                    /root/.ssh/known_hosts updated.
                    Original contents retained as /root/.ssh/known_hosts.old

                    $ exit // Exist from root user


                    Try Again, Hope this works.






                    share|improve this answer





















                    • Note: depending on your shell, you may have to escape the square brackets [ and ] or use quotes.
                      – Phlarx
                      Jan 16 '17 at 19:38


















                    1














                    Its means your remote host key was changed (May be host password change),



                    Your terminal suggested to execute this command as root user



                    $ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]


                    You have to remove that host name from hosts list on your pc/server. Copy that suggested command and execute as a root user.



                    $ sudo su                                                        // Login as a root user

                    $ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net] // Terminal suggested command execute here
                    Host [www.website.net]:4231 found: line 16 type ECDSA
                    /root/.ssh/known_hosts updated.
                    Original contents retained as /root/.ssh/known_hosts.old

                    $ exit // Exist from root user


                    Try Again, Hope this works.






                    share|improve this answer





















                    • Note: depending on your shell, you may have to escape the square brackets [ and ] or use quotes.
                      – Phlarx
                      Jan 16 '17 at 19:38
















                    1












                    1








                    1






                    Its means your remote host key was changed (May be host password change),



                    Your terminal suggested to execute this command as root user



                    $ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]


                    You have to remove that host name from hosts list on your pc/server. Copy that suggested command and execute as a root user.



                    $ sudo su                                                        // Login as a root user

                    $ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net] // Terminal suggested command execute here
                    Host [www.website.net]:4231 found: line 16 type ECDSA
                    /root/.ssh/known_hosts updated.
                    Original contents retained as /root/.ssh/known_hosts.old

                    $ exit // Exist from root user


                    Try Again, Hope this works.






                    share|improve this answer












                    Its means your remote host key was changed (May be host password change),



                    Your terminal suggested to execute this command as root user



                    $ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]


                    You have to remove that host name from hosts list on your pc/server. Copy that suggested command and execute as a root user.



                    $ sudo su                                                        // Login as a root user

                    $ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net] // Terminal suggested command execute here
                    Host [www.website.net]:4231 found: line 16 type ECDSA
                    /root/.ssh/known_hosts updated.
                    Original contents retained as /root/.ssh/known_hosts.old

                    $ exit // Exist from root user


                    Try Again, Hope this works.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Aug 14 '16 at 5:02









                    Jay Patel

                    16.7k85365




                    16.7k85365












                    • Note: depending on your shell, you may have to escape the square brackets [ and ] or use quotes.
                      – Phlarx
                      Jan 16 '17 at 19:38




















                    • Note: depending on your shell, you may have to escape the square brackets [ and ] or use quotes.
                      – Phlarx
                      Jan 16 '17 at 19:38


















                    Note: depending on your shell, you may have to escape the square brackets [ and ] or use quotes.
                    – Phlarx
                    Jan 16 '17 at 19:38






                    Note: depending on your shell, you may have to escape the square brackets [ and ] or use quotes.
                    – Phlarx
                    Jan 16 '17 at 19:38













                    0














                    I had the similar issue, unfortunately I used the GitExtensions HMI and forgot that I wrote a passphrase.
                    With HMI.... forget it ! Do not enter passphrase when you generate your key !






                    share|improve this answer


























                      0














                      I had the similar issue, unfortunately I used the GitExtensions HMI and forgot that I wrote a passphrase.
                      With HMI.... forget it ! Do not enter passphrase when you generate your key !






                      share|improve this answer
























                        0












                        0








                        0






                        I had the similar issue, unfortunately I used the GitExtensions HMI and forgot that I wrote a passphrase.
                        With HMI.... forget it ! Do not enter passphrase when you generate your key !






                        share|improve this answer












                        I had the similar issue, unfortunately I used the GitExtensions HMI and forgot that I wrote a passphrase.
                        With HMI.... forget it ! Do not enter passphrase when you generate your key !







                        share|improve this answer












                        share|improve this answer



                        share|improve this answer










                        answered Jan 22 '16 at 18:28









                        Jerome Vacher

                        30017




                        30017























                            0














                            You can use your "git url" in 'https" URL format in the Jenkinsfile or wherever you want.



                            git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'






                            share|improve this answer


























                              0














                              You can use your "git url" in 'https" URL format in the Jenkinsfile or wherever you want.



                              git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'






                              share|improve this answer
























                                0












                                0








                                0






                                You can use your "git url" in 'https" URL format in the Jenkinsfile or wherever you want.



                                git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'






                                share|improve this answer












                                You can use your "git url" in 'https" URL format in the Jenkinsfile or wherever you want.



                                git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'







                                share|improve this answer












                                share|improve this answer



                                share|improve this answer










                                answered May 11 '16 at 9:58









                                Nitin

                                2,8351823




                                2,8351823























                                    0














                                    I got this message when I tried to git clone a repo that was not mine. The fix was to fork and then clone.






                                    share|improve this answer


























                                      0














                                      I got this message when I tried to git clone a repo that was not mine. The fix was to fork and then clone.






                                      share|improve this answer
























                                        0












                                        0








                                        0






                                        I got this message when I tried to git clone a repo that was not mine. The fix was to fork and then clone.






                                        share|improve this answer












                                        I got this message when I tried to git clone a repo that was not mine. The fix was to fork and then clone.







                                        share|improve this answer












                                        share|improve this answer



                                        share|improve this answer










                                        answered Apr 27 at 1:00









                                        fyodrs

                                        1




                                        1























                                            0














                                            I was facing the same error inside DockerFile during build time while the image was public. I did little modification in Dockerfile.



                                             RUN git clone  https://github.com/kacole2/express-node-mongo-skeleton.git /www/nodejs



                                            This would be because using the git@github.com:... syntax ends up > using SSH to clone, and inside the container, your private key is not > available. You'll want to use RUN git clone > https://github.com/edenhill/librdkafka.git instead.







                                            share|improve this answer


























                                              0














                                              I was facing the same error inside DockerFile during build time while the image was public. I did little modification in Dockerfile.



                                               RUN git clone  https://github.com/kacole2/express-node-mongo-skeleton.git /www/nodejs



                                              This would be because using the git@github.com:... syntax ends up > using SSH to clone, and inside the container, your private key is not > available. You'll want to use RUN git clone > https://github.com/edenhill/librdkafka.git instead.







                                              share|improve this answer
























                                                0












                                                0








                                                0






                                                I was facing the same error inside DockerFile during build time while the image was public. I did little modification in Dockerfile.



                                                 RUN git clone  https://github.com/kacole2/express-node-mongo-skeleton.git /www/nodejs



                                                This would be because using the git@github.com:... syntax ends up > using SSH to clone, and inside the container, your private key is not > available. You'll want to use RUN git clone > https://github.com/edenhill/librdkafka.git instead.







                                                share|improve this answer












                                                I was facing the same error inside DockerFile during build time while the image was public. I did little modification in Dockerfile.



                                                 RUN git clone  https://github.com/kacole2/express-node-mongo-skeleton.git /www/nodejs



                                                This would be because using the git@github.com:... syntax ends up > using SSH to clone, and inside the container, your private key is not > available. You'll want to use RUN git clone > https://github.com/edenhill/librdkafka.git instead.








                                                share|improve this answer












                                                share|improve this answer



                                                share|improve this answer










                                                answered Jul 30 at 13:16









                                                Adiii

                                                5,6333135




                                                5,6333135






























                                                    draft saved

                                                    draft discarded




















































                                                    Thanks for contributing an answer to Stack Overflow!


                                                    • Please be sure to answer the question. Provide details and share your research!

                                                    But avoid



                                                    • Asking for help, clarification, or responding to other answers.

                                                    • Making statements based on opinion; back them up with references or personal experience.


                                                    To learn more, see our tips on writing great answers.





                                                    Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                                                    Please pay close attention to the following guidance:


                                                    • Please be sure to answer the question. Provide details and share your research!

                                                    But avoid



                                                    • Asking for help, clarification, or responding to other answers.

                                                    • Making statements based on opinion; back them up with references or personal experience.


                                                    To learn more, see our tips on writing great answers.




                                                    draft saved


                                                    draft discarded














                                                    StackExchange.ready(
                                                    function () {
                                                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f13363553%2fgit-error-host-key-verification-failed-when-connecting-to-remote-repository%23new-answer', 'question_page');
                                                    }
                                                    );

                                                    Post as a guest















                                                    Required, but never shown





















































                                                    Required, but never shown














                                                    Required, but never shown












                                                    Required, but never shown







                                                    Required, but never shown

































                                                    Required, but never shown














                                                    Required, but never shown












                                                    Required, but never shown







                                                    Required, but never shown







                                                    Popular posts from this blog

                                                    Tonle Sap (See)

                                                    I get strange results when I access the Sqlitedatabase with Unity C# via XAMPP

                                                    Guatemaltekische Davis-Cup-Mannschaft