I successfully added remote (private) GitLab account under Windows 10 in GitAhead but under a Linux openSUSE Leap 15 I got "Connection failed: SSL handshake failed".
Note that I can clone, pull, fetch, commit, push in repositories from repositories in the GitLab I want to add, I also tried to reset SSH handshake with:
$ ssh-keygen -R gitlab.mydomain.net
# Host gitlab.mydomain.net found: line 31
/home/user/.ssh/known_hosts updated.
Original contents retained as /home/user/.ssh/known_hosts.old
$ ssh git#gitlab.mydomain.net
The authenticity of host 'gitlab.mydomain.net (<IP>)' can't be established.
ECDSA key fingerprint is SHA256:**************.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'gitlab.mydomain.net,<IP>' (ECDSA) to the list of known hosts.
Welcome to GitLab, #UserName!
Connection to gitlab.mydomain.net closed.
But it still does not work, anyone knows if there is something to configure to allow it under Linux ?
Thanks
For a starter, check the rights on directories on the server-side. The home-dir as well as the .ssh-dir should be treated with chmod 700. The same is true for the key files.
You should aim for a passwordless login on your server. As soon as this works, GitAhead should be fine. If you have a Git-Shell in your server-side /etc/passwd, replace it by /bin/sh for the sake of sending your pubkey: On the client, enter ssh-copy-id -i yourprivatekeyfile somerandomgituser#ipofyourgitserver. After that, if successful, you can reset the /etc/passwd line back to the Git-Shell.
Related
I have one project on Gitlab and I worked with it for the last few days!
But after a few days it all went off! I added my home PC ssh key in Gitlab project setting, but now I want use git pull for receive new changes in my home PC show me this error:
10:47 AM Update failed
Permission denied (publickey).
Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
10:47 AM Update canceled
Gitlab ssh key image:
How can I fix it?
GitHub isn't able to authenticate you. So, either you aren't setup with an SSH key, because you haven't set one up on your machine, or your key isn't associated with your GitHub account.
You can also use the HTTPS URL instead of the SSH/git URL to avoid having to deal with SSH keys. This is GitHub's recommended method.
Further, GitHub has a help page specifically for that error message, and explains in more detail everything you could check.
I know this problem. After add ssh key, add you ssh key to ssh agent too (from official docs https://help.github.com/articles/generating-ssh-keys/)
ssh-agent -s
ssh-add ~/.ssh/id_rsa
After it, all work fine, git can view proper key, before couldn't.
I have configured Jenkins on a Linux machine and my git repo is on an another Linux server. But when I try to give the URL of the repo to Jenkins I get the following error.
Failed to connect to repository : Command "git -c core.askpass=true ls-remote -h ssh://user#ip/~/export1 HEAD" returned status code 128:
stdout:
stderr: Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
What could be the cause for this?
I have seen that both the systems' rsa key is present in each other's .ssh/known_hosts folder.
I am able to pull or clone code from the repo to a folder in Jenkins system as well. So why is Jenkins not able to take it?
I have also tried the URL user#ip:/fullpath/to/repo
You need to make sure Jenkins is running as the right user (the one who has the keys in ~/.ssh/id_rsa(.pub)
That user might not be the same as the one used in the ssh url: user#ip means you are connecting to ip using an account which has your public key in ~user/.ssh/authorized_key.
So the Jenkins process must be run by an account which has the private and public key, whose public key is in ~user/.ssh/authorized_key on the git server side.
And that account should have done (only once) an ssh-keyscan -H ip >> ~account/.ssh/known_hosts before any ssh attempt, in order to record the git server ip as a known host.
Does it being a bare repo make any difference or change in the URL?
No. The .git at the end of the bare repo folder is optional when used as an url.
Further to #VonC's reply, you can also use the Credentials plugin to define a set of credentials on your Jenkins master that your Jenkins job uses to access your Git repo. This allows you to run Jenkins itself as a different user from there one that has access to the Git repo.
The main problem was the security of the systems. I hadnt checked the authentication mechanisms on my server. The password authentication to the git server was causing the problem because the jenkins machine tries to directly fire a ls-remote to the path. When you do the same thing on the terminal you will be prompted for a password and then itl accept. When I set the password authentication and UsePAM to no and enabled the RSA authentication, pubkey authentication and authorised key setting to yes in the sshd_config file, and restarted, it was able to access the repo and I dint get this error.
I've installed GitLab per https://github.com/gitlabhq/gitlab-recipes/tree/master/install/centos.
The instructions state to add user "git"
adduser --system --shell /sbin/nologin --comment 'GitLab' --create-home --home-dir /home/git/ git
All seemed to work. I then added a project on the GitLab server, and it gave instructions to push to it:
cd existing_git_repo
git remote add origin git#mysite.com:root/bidjunction.git
git push -u origin master
I then went to my client to push to the git server.
[Michael#devserver bidjunction]$ git push -u origin master
The authenticity of host 'mysite.com (123.456.789.01)' can't be established.
RSA key fingerprint is cd:32:3c:5a:4e:33:44:11:df:ee:3s:4b:3a:c2:a4:c2.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'mysite.com,123.456.789.01' (RSA) to the list of known hosts.
Address 123.456.789.01 maps to ve6.phpwebhosting.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
git#mysite.com's password:
Is there a password I should have set? Probably not, and instructions don't address.
Reading System ask password when push project to github, it appears it might be related to SSH.
GitLab provides the following instructions to add a SSH key. I followed them, and first added the key to my general user's home on the server. No change. Then tried logging on a root, and added a key to git's home. Still none, but I am thinking that the client already has my general user's key, thus is not pulling the new git key.
EDIT. Please confirm that I should add these keys to the GitLab server, and not my Linux client.
Any and all help would be very much appreciated.
SSH Keys
SSH key allows you to establish a secure connection between your computer and GitLab
Before generating an SSH key, check if your system already has one by running cat ~/.ssh/id_rsa.pub If your see a long string starting with ssh-rsa or ssh-dsa, you can skip the ssh-keygen step.
To generate a new SSH key just open your terminal and use code below. The ssh-keygen command prompts you for a location and filename to store the key pair and for a password. When prompted for the location and filename you can press enter to use the default. It is a best practice to use a password for an SSH key but it is not required and you can skip creating a password by pressing enter. Note that the password you choose here can't be altered or retrieved.
ssh-keygen -t rsa -C "$your_email"
Use the code below to show your public key.
cat ~/.ssh/id_rsa.pub
Copy-paste the key to the 'My SSH Keys' section under the 'SSH' tab in your user profile. Please copy the complete key starting with ssh- and ending with your username and host.
EDIT 2
Looks like I was confused, and used GitLab's server id_rsa.pub. Guess that doesn't make any sense! I've since corrected it, but now I get this error:
[Michael#devserver ~]$ ssh git#mysite.com
Address 123.456.789.01 maps to ve6.phpwebhosting.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
PTY allocation request failed on channel 0
This account is currently not available.
Connection to mysite.com closed.
[Michael#devserver ~]$
Seems like a SELinux permission issue. Steps to follow:
restorecon -R -v /home/git/.ssh
usermod -s /bin/bash git
Edit your home machine user's .ssh/config to something like:
Host mysite.com
User gitlab_username
Hostname mysite.com
PreferredAuthentications publickey
IdentityFile /home/user/.ssh/id_rsa
Try connecting to the gitlab server ssh -T git#mysite.com. You should see a message welcoming you.
I added it to the installation guide. I have a merge request ready with several enhancements. I will merge it when gitlab 6.8 is released.
I believe you need to set up your global config username and email
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe#example.com
Check if the git user has a no login shell as you specified. Changing that to bash as suggested fixed my problem (usermod -s /bin/bash git).
I've got root access to our production server and I want to deploy the latest version in git to the server but I'm running into the error below when I "git pull" on the folder I want to update.
I've browsed around a bit, but can't find a clear answer on what to do..
The staging server runs on the same machine, but just in a different folder and when I pull on that folder it all goes fine.
I'm not very experienced when it comes to Linux, so please help me out with a clear answer on how to fix :-)
Otherwise I have access to anything I need
p.s.
This has worked in the past, so I'm assuming it's got something to do with the SSH key
Error:
###########################################################
# WARNING: POSSIBLE DNS SPOOFING DETECTED! #
###########################################################
The ECDSA host key for www.site.org has changed,
and the key for the corresponding IP address x.x.x.x
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
###########################################################
# WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! #
###########################################################
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
*************
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:1
remove with: ssh-keygen -f "/root/.ssh/known_hosts" -R gitlab.site.org
ECDSA host key for gitlab.site.org has changed and you have requested strict checking.
Host key verification failed.
In the log you see the following text:
(...)
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:1
remove with: ssh-keygen -f "/root/.ssh/known_hosts" -R gitlab.site.org
ECDSA host key for gitlab.site.org has changed and you have requested strict checking.
Host key verification failed.
So it is a matter of performing the command that is suggested there:
ssh-keygen -f "/root/.ssh/known_hosts" -R gitlab.site.org
Windows:
Go to /Users/Abhilash/.ssh/known_hosts and delete the contents in it and save.
Linux / Mac:
Go to ~/.ssh/
nano known_hosts
remove content inside and save ctrl+O
Note:
You will be promted to save the key while pushing again.
I have also faced the same issue after following these steps it worked for me.
For macOS:
Step 1: Go to Folder or use command+shift+g
Step 2: type "~/.ssh/"
Step 3: Open "known_hosts" file and Remove all the content
Step 4: Now Open terminal and pull from another branch, It will ask for password give your system password.
It will work surely.
All of the other answers introduce security risks.
This error appears because you have a record in your known_hosts file which says that the server should have a particular ssh key. But when you try to connect, the server has sent a different ssh key which does not match the one in your known_hosts file. Your particular error message says:
Offending ECDSA key in /root/.ssh/known_hosts:1
This means that the first line in the known_hosts file is different to what the remote server is sending.
The secure way to fix the issue is as follows:
Find out what the correct key fingerprint should be from a trustworthy source. e.g. Here you can find the correct fingerprints for GitHub and GitLab. (If your organisation self-hosts GitLab, you will need to talk to your administrator to get the ssh key fingerprints.)
CHECK that the existing fingerprint in your known_hosts file is correct.
You can run ssh-keygen -lf ~/.ssh/known_hosts (or /root/.ssh/known_hosts in your case) to generate SHA256 fingerprints from your known_hosts file. Your error message says that the problem is with the first key. Find the equivalent SHA256 fingerprint on GitHub or GitLab and check if it matches exactly.
e.g. Here is the output of the above command:
256 SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw gitlab.com (ECDSA)
and here is the ECDSA SHA256 fingerprint from the GitLab website:
HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw
If the existing fingerprint from known_hosts matches the official fingerprint from the GitHub or GitLab website, then ssh has detected a Man in the Middle (MitM) attack. STOP. Do not connect to the server. Try connecting from a different internet connection. Talk to your administrator.
If the existing fingerprint in known_hosts does not match the official fingerprint, then either you were under a MitM attack previously, or the server hosting GitLab has changed its ssh keys. You can delete the fingerprint from your known_hosts file. (Note: Only delete the specific fingerprint which is causing trouble.) Next time you connect to GitLab, you will be prompted to add the new fingerprint to the known_hosts file.
The authenticity of host 'gitlab.com (172.65.251.78)' can't be established.
ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
Double-check that the fingerprint matches what is shown on the GitHub or GitLab website, then type yes or no accordingly.
Try replacing ssh with:
ssh -oStrictHostKeyChecking=no
since if the key hasn’t been accepted yet, then it will ask do you want to accept it yes/no. Alternatively, you can also do this in your CI file just before the SSH command:
echo "StrictHostKeyChecking no" >> ~/.ssh/config
courtesy:
https://forum.gitlab.com/t/error-host-key-verification-failed/77315/3
if you'd like to remove this message permanently you can edit your ssh config file (~/.ssh/config) to include:
Host {YOUR HOST HERE}
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
I am trying to use
sudo npm install
to install all my dependencies for an application written in nodejs. My OS is Ubuntu 13.04
However, I keep getting this warning:
The authenticity of host 'github.com (192.30.252.131)' can't be established.
RSA key fingerprint is 16:27:ac:a5:76:28:1d:52:13:1a:21:2d:bz:1d:66:a8.
Are you sure you want to continue connecting (yes/no)?
Has anyone encountered this warning before? Is it possible to authenticate and store the fingerprint locally? So I won't need to authenticate again when I enter sudo npm install another time.
Right now, I am unable to enter anything, not even "yes". My terminal just gets stuck, i have to press Ctrl+C to terminate.
Danger ahead, unless you actually don't care about secure communication with github on your local account
Ssh rightly complains that they can't make sure you are indeed connecting to github's server through a secure channel. That might be why github is recommending https access, which works out-of-the-box thanks to its public key infrastructure.
Now, you can have it work, but be aware that it involves caching a public key fingerprint which, if done incorrectly, provides an attacker permanent man-in-the-middle attack.
How to proceed safely?
Option 1 is use https url instead of ssh.
Option 2 is have ssh access work.
Okay, show me option 2
Do ssh -T git#github.com but don't just type "yes".
Check if the hash that is shown matches one of the hashed shown in https://help.github.com/articles/what-are-github-s-ssh-key-fingerprints/ (in your question it does, and see, the page is fetched through https for the same public key infrastructure reasons).
If the hash matches, then connection is indeed safe you can answer "yes" to ssh's question.
Okay, I checked and typed yes, how do I know it works?
Ssh will show something like:
Warning: Permanently added the RSA host key for IP address
'192.30.252.128' to the list of known hosts.
After that, you will either see a message like
Permission denied (publickey).
which is good but shows that you need further configuration, or simply
Hi yourlogin! You've successfully authenticated, but GitHub does not
provide shell access.
which means that all works well and you can retry your first operation.
Notice that if you retry the same ssh command, it should no longer ask the question.
Run ssh -o StrictHostKeyChecking=no git#github.com in command prompt to add the authenticity to your known_hosts. Then you won't get the prompt the next time.
I solved my problem by running
ssh-keyscan github.com >> ~/.ssh/known_hosts
in command prompt. This command will add authenticity to your known_hosts.
You sure you're not accidentally logged in as a different user (this happens to me when I sudo -s / login as root and forget my GitHub account isn't linked to that user).
I landed here because I was getting this error and not understanding why. It turns out I had a typo in my npm command:
npm install -P -E #angular/common #angular/compiler #angular/core #angular/forms
#angular/platform-browser #angular/router #angular/animations# angular/platform-browser-dynamic
Notice how the end of the line reads #angular/animations# angular/platform-browser-dynamic.
NPM interprets the last "package" as being a github repo and that is where the error comes from.
I know this does not actually answer the question but I put it up just in case anyone else encounters this by making a similar mistake.
If you have this type problem
The authenticity of host 'github.com (192.30.252.131)' can't be established.
RSA key fingerprint is 16:27:ac:a5:76:28:1d:52:13:1a:21:2d:bz:1d:66:a8.
Are you sure you want to continue connecting (yes/no)?
don't worry, follow these steps:
Step 1: yes [press enter]
then you'll get:
Please type 'yes', 'no' or the fingerprint:
Step 2: copy fingerprint and paste here [press enter ]
Stéphane Gourichon's 2016 answer mentions:
Do ssh -T git#github.com but don't just type "yes".
Check if the hash that is shown matches one of the hashed shown in "GitHub's SSH key fingerprints".
(in your question it does, and see, the page is fetched through https for the same public key infrastructure reasons).
Another way to check, this time programmatically, if the GitHub host keys match, is to use the GitHub API (Jan. 2022):
GitHub’s SSH host keys are now published in the API
The GitHub metadata endpoint (api.github.com/meta) now contains our SSH host keys.
(We'll continue offering host key fingerprints as well.)
{
// new entry
"ssh_keys": [
"ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl",
"ecdsa-sha2-nistp256 >AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=",
"ssh-rsa >AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ=="
],
// existing entry
"ssh_key_fingerprints": [
"SHA256_RSA": "nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8",
"SHA256_ECDSA": "p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM",
"SHA256_ED25519": "+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU"
],
// ... rest of payload
}
These keys are in the OpenSSH known_hosts format for easy inclusion into existing known_hosts files.
This will make it easier to preconfigure systems which expect to connect via SSH.
For example, you can prime your CI runners with these keys before starting to fetch from GitHub.
The keys returned from the API include both SSH host keys that we're actively using, plus any that we're advertising via host key rotation for future use.
Currently, we're not offering any keys via rotation that aren't actively in use, but if we announce new host keys in the future, you can find them here as well during the rotation period.
See the meta API endpoint to learn more.
Github just made changes to their ip address infrastructure. You can read here for more details https://github.com/blog/1606-ip-address-changes . Also, I have never seen a problem like this before. Is you package.json containing a git depency cloned via ssh?
Try echo 'yes' | sudo npm install. This may solve your problem. If it does not, try cloning via HTTPS instead or download the module as a tarball instead, which can be done like this https://api.github.com/repos/username/reponame/tarball
I was using npm ci but the package-lock.json file had a lot of git+ssh:// URLs which triggered this error message.
Bashed on the accepted answer here, I used a little sed script to replace all the ssh:// URLs with https:// URLs:
sed -i 's|git+ssh://git#github.com|https://github.com|' ./package-lock.json
I hope that may help some people in a similar situation.
This is a quick workaround. A more permanent solution would be to fix the URLs in the package.json file, in order to build an improved package-lock.json file.
Just in case you stumble upon that in IntelliJ IDEA (or any other IntelliJ product), go to Version Control > GitHub and uncheck [✓] Clone git repositories using ssh.
Run ssh github.com and type yes and it should fail. Then run your command again. If not try ssh github.com again as they have multiple IP's and you might need all of them.