Even after changing one of the BBB's IP, when i tried to connect, its configuration is reverting back to default, did somebody tried this, if so let me know with exact steps for the solution.
problem:
root#silvan-DL-H61MXP:~# ssh root#192.168.7.2
###########################################################
# 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 RSA key sent by the remote host is
7d:0c:75:6f:f0:15:2f:13:39:f9:94:ba:88:30:61:e9.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending RSA key in /root/.ssh/known_hosts:1
remove with: ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.7.2
RSA host key for 192.168.7.2 has changed and you have requested strict checking.
Host key verification failed.
The solution for connecting with ssh to such development systems, which often loose their configuration is to disable host key checking and storage for them.
In your case this can be done by putting this into ~/.ssh/config:
Host 192.168.7.*
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
However, be careful not to disable host key checking and storage for normal systems as this would open them up for man-in-the-middle attacks.
Related
I can't configure SSH key-authentication on my new VDS server. After I've done ssh-copy-id I still get password prompt for user.
To debug I added LogLevel DEBUG3 in /etc/ssh/sshd_config and restarted systemctl restart sshd and saw in logs /var/log/secure this message:
RSA key is not allowed
Why does this happen and how do I fix it?
OpenSSH disabled RSA scheme by default for security reasons.
Therefore the best option is to create new local keys using more secure algo:
ssh-keygen -t ed25519
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.
ssh-agent forwarding can be accomplished with ssh -A ....
Most references I have found state that the local machine must configure ~/.ssh/config to enable AgentForwarding with the following code:
Host <trusted_ip>
ForwardAgent yes
Host *
ForwardAgent no
However, with this configuration, I am still able to see my local machines keys when tunneling into a remote machine, with ssh -A user#remote_not_trusted_ip, and running ssh-add -l.
From the configuration presented above, I would expect that the ssh-agent forwarding would fail and the keys of the local machine would not be listed by ssh-add -l.
Why is the machine #remote_not_trusted_ip able to access the ssh-agent forwarded keys even though the ~/.ssh/config file states the following?
Host *
ForwardAgent no
How can i prevent ssh-agent from forwarding keys to machines not explicitly defined in the ~/.ssh/config?
How can i prevent ssh-agent from forwarding keys to machines not explicitly defined in the ~/.ssh/config?
It is the default behavior. If you do not allow it in ~/.ssh/config it will not be forwarded. But the command-line arguments have higher priority so it overwrites what is defined in the configuration,as explained in the manual page for ssh_config:
ssh(1) obtains configuration data from the following sources in the following order:
command-line options
user's configuration file (~/.ssh/config)
system-wide configuration file (/etc/ssh/ssh_config)
So as already said, you just need to provide correct arguments to ssh.
So back to the questions:
Why is the machine #remote_not_trusted_ip able to access the ssh-agent forwarded keys even though the ~/.ssh/config file states the following?
Host *
ForwardAgent no
Because the command-line argument -A has higher priority than the configuration files.
How can I prevent ssh-agent from forwarding keys to machines not explicitly defined in the ~/.ssh/config?
Do not use -A command-line option if you do not want forward your ssh-agent. Use -a command-line option instead.
You are using -A option to connect. man ssh says :
-A Enables forwarding of the authentication agent connection.
You should connect without -A, just using :
ssh user#remote_not_trusted_ip
CLI args will have priority on ssh config file.
By the way, if you want to connect to your trusted ip without forwarding, you can also use :
ssh -a user#trusted_ip
-a Disables forwarding of the authentication agent connection.
This is over a year old, but I encountered the same issue and landed on a config option that works.
I had a problem when I connected from my home computer to my work computer that Git commands no longer worked. I figured out that it was because the connecting home computer's public key was forwarded, which was not configured for that GitHub account.
The -a command line options fixed the problem by not forwarding the authentication agent connection. I also thought that the equivalent ~/.ssh/config option would be this:
ForwardAgent no
When that didn't work I looked for other configuration variables, and finally found that this one worked.
IdentityAgent none
This part of the man-page is crucial:
Since the first obtained value for each parameter is used, more
host-specific declarations should be given near the beginning of the
file, and general defaults at the end.
Put your Host * with ForwardAgent yes at the end and the specific Host with ForwardAgent, not at the start of the .ssh/config
Not an answer to the question, and maybe just semantics:
Why is the machine #remote_not_trusted_ip able to access the ssh-agent forwarded keys even though the ~/.ssh/config file states the following?
My understanding is that authentication keys are never "forwarded" to a remote computer. Rather ssh-agent forwards authentication challenges from a remote server back to the computer that holds the authentication private key through whatever chain of remote computers the ssh connection is running through.
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 try to use ssh to login in the Openstack server built for the class. I download the .pem key from server. By putty, I login successfully with .ppk key (generate .ppk key by .pem using putty keygen). But it's not work on ssh. Is there something I missed?
My command
ssh -l ubuntu -i ~/.ssh/xxx.pem xxx.edu -p 18922
Error msg
###########################################################
# 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 RSA key sent by the remote host is
(xxx).
Please contact your system administrator.
Add correct host key in /Users/xxx/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/xxx/.ssh/known_hosts:2
RSA host key for [xxx.edu]:18922 has changed and you have requested strict checking.
Host key verification failed.
Thanks for Anil Vishnoi's comment!
Remove
/Users/xxx/.ssh/known_hosts
and use my original command by passing pem key
ssh -l ubuntu -i ~/.ssh/xxx.pem xxx.edu -p 18922
I can ssh to Openstack server directly.