Then I got the prompt to add it to known hosts list, the question might be this one: 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. 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).
What worked for me was to first add my SSH key of the new computer, I followed these instructions from GitLab - add SSH key. 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. I strongly encourage you to consider having users authenticate with keys as well.
#Gitkraken configured ssh key is invalid update#
(If the wrong key is in /etc, someone with administrative privileges will have to update the system-wide file.) The reason for this prompt is domain.example is no longer in your known_hosts after deleting it and presumably not in the system’s /etc/ssh/ssh_known_hosts, so ssh has no way to know whether the host on the other end of the connection is really domain.example. Or, equivalently, let ssh do it for you next time you connect with git fetch, git pull, or git push (or even a plain ol’ ssh domain.example) by answering yes when prompted The authenticity of host 'domain.example (a.b.c.d)' can't be established.Īre you sure you want to continue connecting (yes/no)?
If this does not seem fishy to you, remove the old key from your local cache by editing $/.ssh/known_hosts to remove the line for domain.example or letting an SSH utility do it for you with ssh-keygen -R domain.exampleįrom here, record the updated key either by doing it yourself with ssh-keyscan -t rsa domain.example > ~/.ssh/known_hosts The host key for domain.example has changed. Clients remember the host key associated with a particular address and refuse to connect if a host key appears to change. You are connecting via the SSH protocol, as indicated by the ssh:// prefix on your clone URL.
0 kommentar(er)
