Git error: “Host Key Verification Failed” when connecting to remote repository
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
add a comment |
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
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
add a comment |
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
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
git ssh ssh-keys
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
add a comment |
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
add a comment |
14 Answers
14
active
oldest
votes
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.
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_hostsis 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/sshand not under~/.ssh.
– Greg Bacon
Feb 13 at 15:51
add a comment |
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
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
add a comment |
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 -
mkdir -p ~/.ssh
ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
ssh-keygen -t rsa -C "user.email"- Add the id_rsa.pub key to SSH keys list on your GitHub profile.
3
It should beknown_hosts.
– jcoffland
Oct 15 '15 at 20:39
You could replace 1 & 2 with simplytouch ~/.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. Thetouchcommand would fail in case~/.sshdirectory does not exist, so step 1 was still required. Also you don't need totouchthe file before using>>redirection. It will be created if necessary (but just the file, not entire path, so stillmkdir -pis needed). The-poption make it work in case the directory already exists.
– Tadeusz Łazurski
Jun 10 at 17:14
add a comment |
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.
This is the right answer if you never get prompted.
– Matt Hagemann
Jul 7 at 8:23
add a comment |
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.
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
add a comment |
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
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
add a comment |
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
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
add a comment |
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.
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
add a comment |
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.
add a comment |
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.
Note: depending on your shell, you may have to escape the square brackets [ and ] or use quotes.
– Phlarx
Jan 16 '17 at 19:38
add a comment |
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 !
add a comment |
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'
add a comment |
I got this message when I tried to git clone a repo that was not mine. The fix was to fork and then clone.
add a comment |
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.
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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_hostsis 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/sshand not under~/.ssh.
– Greg Bacon
Feb 13 at 15:51
add a comment |
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.
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_hostsis 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/sshand not under~/.ssh.
– Greg Bacon
Feb 13 at 15:51
add a comment |
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.
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.
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_hostsis 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/sshand not under~/.ssh.
– Greg Bacon
Feb 13 at 15:51
add a comment |
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_hostsis 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/sshand 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
add a comment |
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
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
add a comment |
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
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
add a comment |
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
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
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
add a comment |
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
add a comment |
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 -
mkdir -p ~/.ssh
ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
ssh-keygen -t rsa -C "user.email"- Add the id_rsa.pub key to SSH keys list on your GitHub profile.
3
It should beknown_hosts.
– jcoffland
Oct 15 '15 at 20:39
You could replace 1 & 2 with simplytouch ~/.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. Thetouchcommand would fail in case~/.sshdirectory does not exist, so step 1 was still required. Also you don't need totouchthe file before using>>redirection. It will be created if necessary (but just the file, not entire path, so stillmkdir -pis needed). The-poption make it work in case the directory already exists.
– Tadeusz Łazurski
Jun 10 at 17:14
add a comment |
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 -
mkdir -p ~/.ssh
ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
ssh-keygen -t rsa -C "user.email"- Add the id_rsa.pub key to SSH keys list on your GitHub profile.
3
It should beknown_hosts.
– jcoffland
Oct 15 '15 at 20:39
You could replace 1 & 2 with simplytouch ~/.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. Thetouchcommand would fail in case~/.sshdirectory does not exist, so step 1 was still required. Also you don't need totouchthe file before using>>redirection. It will be created if necessary (but just the file, not entire path, so stillmkdir -pis needed). The-poption make it work in case the directory already exists.
– Tadeusz Łazurski
Jun 10 at 17:14
add a comment |
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 -
mkdir -p ~/.ssh
ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
ssh-keygen -t rsa -C "user.email"- Add the id_rsa.pub key to SSH keys list on your GitHub profile.
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 -
mkdir -p ~/.ssh
ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
ssh-keygen -t rsa -C "user.email"- Add the id_rsa.pub key to SSH keys list on your GitHub profile.
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 beknown_hosts.
– jcoffland
Oct 15 '15 at 20:39
You could replace 1 & 2 with simplytouch ~/.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. Thetouchcommand would fail in case~/.sshdirectory does not exist, so step 1 was still required. Also you don't need totouchthe file before using>>redirection. It will be created if necessary (but just the file, not entire path, so stillmkdir -pis needed). The-poption make it work in case the directory already exists.
– Tadeusz Łazurski
Jun 10 at 17:14
add a comment |
3
It should beknown_hosts.
– jcoffland
Oct 15 '15 at 20:39
You could replace 1 & 2 with simplytouch ~/.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. Thetouchcommand would fail in case~/.sshdirectory does not exist, so step 1 was still required. Also you don't need totouchthe file before using>>redirection. It will be created if necessary (but just the file, not entire path, so stillmkdir -pis needed). The-poption 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
add a comment |
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.
This is the right answer if you never get prompted.
– Matt Hagemann
Jul 7 at 8:23
add a comment |
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.
This is the right answer if you never get prompted.
– Matt Hagemann
Jul 7 at 8:23
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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
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
add a comment |
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
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
add a comment |
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
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
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
add a comment |
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
add a comment |
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
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
add a comment |
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
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
add a comment |
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
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
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
add a comment |
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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Apr 5 at 16:51
Julian Knight
3,86111630
3,86111630
add a comment |
add a comment |
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.
Note: depending on your shell, you may have to escape the square brackets [ and ] or use quotes.
– Phlarx
Jan 16 '17 at 19:38
add a comment |
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.
Note: depending on your shell, you may have to escape the square brackets [ and ] or use quotes.
– Phlarx
Jan 16 '17 at 19:38
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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 !
add a comment |
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 !
add a comment |
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 !
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 !
answered Jan 22 '16 at 18:28
Jerome Vacher
30017
30017
add a comment |
add a comment |
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'
add a comment |
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'
add a comment |
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'
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'
answered May 11 '16 at 9:58
Nitin
2,8351823
2,8351823
add a comment |
add a comment |
I got this message when I tried to git clone a repo that was not mine. The fix was to fork and then clone.
add a comment |
I got this message when I tried to git clone a repo that was not mine. The fix was to fork and then clone.
add a comment |
I got this message when I tried to git clone a repo that was not mine. The fix was to fork and then clone.
I got this message when I tried to git clone a repo that was not mine. The fix was to fork and then clone.
answered Apr 27 at 1:00
fyodrs
1
1
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Jul 30 at 13:16
Adiii
5,6333135
5,6333135
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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