I was already able to connect to the server via ssh properly. But recently after changing the server fixed-IP address and domain name, I cannot connect to the server by DNS name. Despite, I can ssh to the server with its IP address. The error of ssh with domain name is the following:
###########################################################
# WARNING: POSSIBLE DNS SPOOFING DETECTED! #
###########################################################
The DSA host key for example.com has changed,
and the key for the corresponding IP address X.X.X.X
has a different value. 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.
Offending key for IP in /home/.ssh/known_hosts:10
remove with: ssh-keygen -f "/home/.ssh/known_hosts" -R X.X.X.X
###########################################################
# 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 DSA key sent by the remote host is
*:*:*:*:*:....
Please contact your system administrator.
Add correct host key in /home/.ssh/known_hosts to get rid of this message.
Offending DSA key in /home/.ssh/known_hosts:11
remove with: ssh-keygen -f "/home/.ssh/known_hosts" -R example.com
DSA host key for example.com has changed and you have requested strict checking.
Host key verification failed.
The answer is in the question:
ssh-keygen -f "/home/.ssh/known_hosts" -R example.com
You will get more info on the first google hit for the big message. WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
You should remove line 10 from your known_hosts because the system signalized you about the problem
Offending key for IP in /home/.ssh/known_hosts:10
I moved my ~/.ssh/known_hosts file and retried it worked. I guess the effect will just confirmation prompt for future connections, for the hosts that are there in known_hosts
I encountered the same problem.
I think the problem is that the item recorded in the "known-hosts" does not match something of the remote host(sorry, I don't know what the something is).
In my case, I just deleted the item in "known-hosts" according to the IP address of the remote host and ran ssh command again. Then it worked.
If you have got a backup of your /etc/ssh directory and want to restore it, just use
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user#hostname
for connecting once without checking.
Source: ssh man page
I faced same problem when I tried to do a pull.
Fix:
I deleted .ssh/known_hosts file on my system and retried pull, it worked.
Why this happened:
We had a gitlab migration. known_host file store gitlab ip, so it was not able to establish connectivity with existing host.
Just follow what is suggested.
sudo ssh-keygen -f "/root/.ssh/known_hosts" -R ip
sudo ssh-keygen -f "/root/.ssh/known_hosts" -R host
These commands will remove old fingerprints, and then you will be asked:
The authenticity of host 'host (ip)' can't be established.
ECDSA key fingerprint is SHA256:YrD+1E4JmdeObwEyQW3zGqNhXE//64MMZrHHaInE7w0.
Are you sure you want to continue connecting (yes/no)?
Write "yes" and you will see such message:
Warning: Permanently added 'host,ip' (ECDSA)
to the list of known hosts.
This will create new fingerprint in the /root/.ssh/known_hosts file.
For me, it couldn't find the file so I had to flip the file path and domain name like so:
ssh-keygen -R example.com -f ~/.ssh/known_hosts
Just delete the known_hosts file
$ rm .ssh/known_hosts
$ ssh ras.mydomain.com
Try connecting with ssh again
ssh username#server-ip-here
Related
I have two ways of accessing my remote host ssh server:
using its local IP addres
using its public IP address
Yesterday, I reinstalled my SSH server on the remote host and I updated my known hosts file for the local IP address. I am now off of my local network and trying to connect to my server using its public IP address and I realized I forgot to update my known hosts file after reinstalling the SSH service. This is giving me the common error below.
###########################################################
# 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
MD5:FINGERPRINT.
Please contact your system administrator.
Add correct host key in /Users/user/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /Users/user/.ssh/known_hosts:25
ECDSA host key for [PUBLIC IP]:PORT has changed and you have requested strict checking.
Host key verification failed.
I'm 99% sure this is because I changed the SSH server, however, if I wanted to double check and verify, how would I do this?
My question is
How can I verify the new fingerprint of the remote host against the fingerprint saved for the local IP address of the server?
What I've Done
I ran the following command: ssh-keygen -lv -f ~/.ssh/known_hosts and found the SHA256 fingerprint saved for the local ip address of my server.
I compared this to the SHA256 fingerprint being sent to me from my remote host, and they appear to be identical.
How can I be 100% sure? Did I do this properly?
When you say "updated" your known_hosts file, does that also mean you removed the old entry?
You can run this quick oneliner to quickly get the current fingerprint via local ip and public ip.
ssh-keyscan -t rsa <Local IP of host> <Remote IP of host> | ssh-keygen -l -f -
Here is a usage example scanning one of my Linux systems using the loopback interface as the second scan address.
$ ssh-keyscan -t rsa 127.0.0.1 10.10.40.20 | ssh-keygen -l -f -
# 127.0.0.1:22 SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.5
# 10.10.40.20:22 SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.5
2048 SHA256:538+RXBboFrYZDfYBdRpZs8EymGVe9SzznL7dA1jW9g 127.0.0.1 (RSA)
2048 SHA256:538+RXBboFrYZDfYBdRpZs8EymGVe9SzznL7dA1jW9g 10.10.40.20 (RSA)
I have a server called master-instance-node and a server called slave-instance-node-1. In the master-instance-node I have Ansible installed, I modified the /etc/ansible/hosts file and added the following
[webservers]
slave-instance-node-1
Then I try the following command
ansible webservers -a "w " -u USERNAME but I get the following error:
slave-instance-node-1 | UNREACHABLE! => {
"changed": false,
"msg": "Failed to connect to the host via ssh: ###########################################################\r\n# WARNING: POSSIBLE DNS SPOOFING DETECTED! #\r\n###########################################################\r\nThe ECDSA host key for slave-instance-node-1 has changed,\r\nand the key for the corresponding IP address XX.XXX.X.XX\r\nis unknown. This could either mean that\r\nDNS SPOOFING is happening or the IP address for the host\r\nand its host key have changed at the same time.\r\n###########################################################\r\n# WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! #\r\n###########################################################\r\nIT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!\r\nSomeone could be eavesdropping on you right now (man-in-the-middle attack)!\r\nIt is also possible that a host key has just been changed.\r\nThe fingerprint for the ECDSA key sent by the remote host is\nSHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.\r\nPlease contact your system administrator.\r\nAdd correct host key in /home/USERNAME/.ssh/known_hosts to get rid of this message.\r\nOffending ECDSA key in /home/USERNAME/.ssh/known_hosts:1\r\n remove with:\r\n ssh-keygen -f \"/home/USERNAME/.ssh/known_hosts\" -R \"slave-instance-node-1\"\r\nECDSA host key for slave-instance-node-1 has changed and you have requested strict checking.\r\nHost key verification failed.",
"unreachable": true
}
I thought the known hosts file is updated automatically in GCP. What does this error mean and how do I fix it?
In addition to other commentators, you may check which IP your instances are using. If your DNS is configured for the external IPs, you may prefer static external IP to avoid this error after instance reboot. The external addressees are ephemeral, and the issue may occur not only after redeployment, after reboot also. You may be interested in this doc https://cloud.google.com/compute/docs/ip-addresses#externaladdresses
Thanks to the comments in my question I was able to figure out the answer. First I had to remove the known host using the command remove with: ssh-keygen -f "/home/USERNAME/.ssh/known_hosts" -R "slave-instance-node-1". and I also had to set export ANSIBLE_HOST_KEY_CHECKING=false.
Then, I had to add the following line to the /etc/ansible/hosts file next to the server name/ip ansible_user=USERNAME. And finally I had to add the following line inside the /etc/ansible/ansible.cfg file private_key_file = /path/to/file
I try to copy a file to my remote server with scp.
sudo scp atlassian-jira-6.4-x64.bin username#ip-adress:/
When I execute, I get the error:
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
(fingerprint)
Please contact your system administrator.
Add correct host key in /var/root/.ssh/known_hosts to get rid of this message.
Offending RSA key in /var/root/.ssh/known_hosts:1
RSA host key for IPADRESS has changed and you have requested strict checking.
Host key verification failed.
So I removed the known_hosts file from ~/.ssh and tried the command again. But still there is this message coming up. Where do I need to modify my files then besides the .ssh folder?
Edit the known_host file under following directory using vim editor on terminal.
vi /var/root/.ssh/known_hosts OR /root/.ssh/known_hosts
delete all lines using dd command and save the known_hosts file using :wq! and restart your sshd service.
service sshd restart
In case if the problem is repetitive, you can try to use this method.
Add the following lines to the beginning of the SSH configuration file.
Host *
StrictHostKeyChecking no
UserKnownHostsFile=/dev/null
or for a specific host
Host localhost
HostName localhost
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 months ago.
Improve this question
I've reinstalled my server and I am getting these messages:
[user#hostname ~]$ ssh root#pong
###########################################################
# 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
6e:45:f9:a8:af:38:3d:a1:a5:c7:76:1d:02:f8:77:00.
Please contact your system administrator.
Add correct host key in /home/hostname /.ssh/known_hosts to get rid of this message.
Offending RSA key in /var/lib/sss/pubconf/known_hosts:4
RSA host key for pong has changed and you have requested strict checking.
Host key verification failed.
I have tried various solutions that I found on the Internet. My known_hosts file (normally in ~/.ssh/known_hosts) is in /var/lib/sss/pubconf/known_hosts. I've tried to edit it, but it remains in one state. I have installed ipa-client and have Fedora 19. How do I resolve this warning?
All the answers answered so far work only if you do not have Freeipa installed.
The right answer for freeipa in comments below from adrin is here.
Here is the simplest solution:
ssh-keygen -R <host>
For example,
ssh-keygen -R 192.168.3.10
From the ssh-keygen man page:
-R hostname Removes all keys belonging to hostname from a known_hosts file. This option is useful to delete hashed hosts (see the -H option above).
Use
ssh-keygen -R [hostname]
Example with an ip address/hostname would be:
ssh-keygen -R 168.9.9.2
This will update the offending of your host from the known_hosts. You can also provide the path of the known_hosts with -f flag.
I had this same error occur after I recreated a Digital Ocean Ubuntu image. I used the following command with my server IP in place of [IP_ADDRESS]
ssh-keygen -R [IP_ADDRESS]
The sledgehammer is to remove every known host in one fell swoop:
rm ~/.ssh/known_hosts
On Monterey
sudo rm /var/root/.ssh/known_hosts
I come up against this as we use small subnets of short-lived servers from a jump box, and frequently have internal IP address reuse of servers that share the same ssh key.
When you reinstall the server its identity changes, and you'll start to get this message. Ssh has no way of knowing whether you've changed the server it connects to, or a server-in-the-middle has been added to your network to sniff on all your communications - so it brings this to your attention.
Simply remove the key from known_hosts by deleting the relevant entry:
sed '4d' -i /var/lib/sss/pubconf/known_hosts
The 4d is on the account of Offending RSA ...known_hosts:4
The problem is that you've previously accepted an SSH connection to a remote computer and that remote computer's digital fingerprint or SHA256 hash key has changed since you last connected. Thus when you try to SSH again or use github to pull code, which also uses SSH, you get an error. Why? Because you're using the same remote computer address as before but the remote computer is responding with a different fingerprint. Therefore, it's possible that someone is spoofing the computer you previously connected to. This is a security issue.
If you're 100% sure that the remote computer isn't compromised, hacked, being spoofed, etc then all you need to do is delete the entry in your known_hosts file for the remote computer. That will solve the issue as there will no longer be a mismatch with SHA256 fingerprint IDs when connecting.
On Mac here's what I did:
1) Find the line of output that reads RSA host key for servername:port has changed and you have requested strict checking. You'll need both the servername and potentially port from that log output.
2) Back up the SSH known hosts file cp /Users/yourmacusername/.ssh/known_hosts /Users/yourmacusername/.ssh/known_hosts.bak
3) Find the line where the computer's old fingerprint is stored and delete it. You can search for the specific offending remote computer fingerprint using the servername and port from step #1. nano /Users/yourmacusername/.ssh/known_hosts
4) CTRL-X to quit and choose Y to save changes
Now type ssh -p port servername and you will receive the original prompt you did when you first tried to SSH to that computer. You will then be given the option to save that remote computer's updated SHA256 fingerprint to your known_hosts file. If you're using SSH over port 22 then the -p argument is not necessary.
Any issues you can restore the original known_hosts file: cp /Users/yourmacusername/.ssh/known_hosts.bak /Users/yourmacusername/.ssh/known_hosts
As many have already said, use ssh-keygen, i.e.
ssh-keygen -R pong
Also, you may like to consider temporarily turning off host key checking:
ssh -oStrictHostKeyChecking=no root#pong
Works for me!
Error: Offending RSA key in /var/lib/sss/pubconf/known_hosts:4
This indicates you have an offending RSA key at line no. 4
Solution 1:
1. vi /var/lib/sss/pubconf/known_hosts
2. remove line no: 4.
3. Save and Exit, and Retry.
Solution 2:
ssh-keygen -R "you server hostname or ip"
OR
Solution 3:
sed -i '4d' /root/.ssh/known_hosts
This will remove 4th line of /root/.ssh/known_hosts in place(-i).
I used the solution of mockinterface, though the sed -i didn't quite work
I solved it by deleting the line by hand with vim:
sudo vim /var/lib/sss/pubconf/known_hosts
You can use any other text editor you want, but probably you'll need to show your administrative privileges
FINAL Solution!
It is showing due to the stored invalid ECDSA key. So we have to remove the ECDSA key from our master/controller machine by using the below command:
ssh-keygen -R 192.168.0.132
Here 192.168.0.132 is the remote system IP.
Edit /home/hostname /.ssh/known_hosts,and delete the 4 lines, and save it.
Then run ssh root#pong again, you will see message like this:Are you sure you want to continue connecting (yes/no)? yes, just print yes.
Note: If you got some problem, read the hints first, it will help.
The other answers here are good and working, anyway, I solved the problem by deleting ~/.ssh/known_hosts. This certainly solves the problem, but it's probably not the best approach.
updated your ssh key, getting the above message is normal.
Just edit ~/.ssh/known_hosts and delete line 4, as the message pointed you
Offending RSA key in /Users/isaacalves/.ssh/known_hosts:4
or use ssh-keygen to delete the invalid key
ssh-keygen -R "you server hostname or ip"
This is because your remote computer settings have changed. Remove your current keys for that.
vim /root/.ssh/known_hosts
Delete the line of the IP you are connecting.
In my case it happened because I previously had ssh connection with a machine with same ip(say 192.152.51.10) and the system was considering the RSA key(stored in /home/user_name/.ssh/known_hosts) of the previous host which resulted in mismatch.
To resolve this issue, you have to remove previously stored RSA key for the ip 192.152.51.10.
ssh-keygen -f "/home/user_name/.ssh/known_hosts" -R 192.152.51.10
Simple one-liner solution, tested on mac:
sed '/212.156.48.110/d' ~/.ssh/known_hosts > ~/.ssh/known_hosts
Deletes only the target ssh host IP from know hosts.
where 212.156.48.110 is replaced by the target host IP address.
Cause: Happened because the target IP was already known for a different machine due to port forwarding. Deleting the target IP before connecting will fix the issue.
I use PowerShell in Windows 10 for ssh.
My problem was in the Windows directory: C:\Users\youruser\.ssh
Delete the file known_hosts in that directory to forget the old value.
You may also use use File Explorer to locate and delete the file.
If you are trying to connect to running docker container on port 2222 with the command and you get the error
mian#tdowrick2~$ ssh pos#localhost -p 2222
Then to solve this problem, on your local computer (i.e. host machine not container) go to cd ~/.ssh/ and open known_hosts file with text editor. Remove the line starting with [localhost]:2222 and save the file. Now try to ssh again
mian#tdowrick2~$ ssh pos#localhost -p 2222
Error will disappear but you have to do it each time the container restart.
My solution is:
vi ~/.ssh/known_hosts
delete the line that contains your want connected ip.
This is better than delete all of the known_hosts
Remove that the entry from known_hosts using:
ssh-keygen -R *ip_address_or_hostname*
This will remove the problematic IP or hostname from known_hosts file and try to connect again.
From the man pages:
-R hostname
Removes all keys belonging to hostname from a known_hosts file. This option is useful to delete hashed hosts (see the -H option
above).
Sometimes, if for any reason, you need to reinstall a server, when connecting by ssh we will find that you server say that the identification has changed.
If we know that it is not an attack, but that we have reinstated the system, we can remove the old identification from the known_hosts using ssh-keygen:
ssh-keygen -R <host/ip:hostname>
root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old
When connecting again we will ask you to validate the new fingerprint:
ssh -l user <host/ip:hostname>
The authenticity of host '<host/ip:hostname>' can't
be established.
RSA key fingerprint is 3f:3d:a0:bb:59:24:35:6d:e5:a0:1a:3f:9c:86:81:90.
Are you sure you want to continue connecting (yes/no)? yes
Use this command:
truncate -s 0 /home/SYSTEM_NAME/.ssh/known_hosts
I had this problem, and the reason is very simple, I have a duplicated IP address to ssh login, so after modify this problem, everthing is solved.
Only client side problem(duplicate key for ip):
Solve variants:
For clear one ip(default port 22):
ssh-keygen -f -R 7.7.7.7
For one ip(non default port):
ssh-keygen -f -R 7.7.7.7:333
Fast clear all ips:
cd ~; rm .ssh/known_hosts
7.7.7.7 - ssh your server ip connect
333 - non standart port
Just do:
cd /home/user/.ssh/ -> here user will be your username, i.e. /home/jon/ for example.
Then
gedit known_hosts & and delete the contents inside it.
Now ssh again, it should work.
I had the same error in my machine, and I clear the known_hosts file, and after that, it works fine.
Simply clear the known_hosts which is present in /home/{username}/.ssh/known_hosts
vi /home/{username}/.ssh/known_hosts
remove every line inside known hosts and exit after that you will be able to login.
OR
run this command
ssh-keygen -R "hostname/ip_address"
SOLUTION:
1- delete from "$HOME/.ssh/known_hosts" the line referring to the host towards which is impossible to connect.
2- execute this command: ssh-keygen -R "IP_ADDRESSorHOSTNAME" (substitute "IP_ADDRESSorHOSTNAME" with your destination ip or destination hostname)
3- Retry ssh connection (if it fails please check permission on .ssh directory, it has to be 700)
My solution on UBUNTU (linux):
1.You have to delete the content from "known_hosts" file which is in "/home/YOUR_USERNAME/.ssh/known_hosts"
2.Generate a new ssh key like "ssh-keygen -t rsa -C "your.email#example.com" -b 4096"
3.Copy-paste your new ssh key in your git repository (gitlab in my case) SSH keys.
It works for me !
AWS EC2.
Find the ip in the message it gives you.
run
vim /home/ec2-user/.ssh/known_hosts
Use the arrow keys to find the ip from the message and click.
dd
This will delete that line then run escape
:wp
This will save then you are good to go.
When i ssh to a machine, sometime i get this error warning and it prompts to say "yes" or "no". This cause some trouble when running from scripts that automatically ssh to other machines.
Warning Message:
The authenticity of host '<host>' can't be established.
ECDSA key fingerprint is SHA256:TER0dEslggzS/BROmiE/s70WqcYy6bk52fs+MLTIptM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pc' (ECDSA) to the list of known hosts.
Is there a way to automatically say "yes" or ignore this?
Depending on your ssh client, you can set the StrictHostKeyChecking option to no on the command line, and/or send the key to a null known_hosts file. You can also set these options in your config file, either for all hosts or for a given set of IP addresses or host names.
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
EDIT
As #IanDunn notes, there are security risks to doing this. If the resource you're connecting to has been spoofed by an attacker, they could potentially replay the destination server's challenge back to you, fooling you into thinking that you're connecting to the remote resource while in fact they are connecting to that resource with your credentials. You should carefully consider whether that's an appropriate risk to take on before altering your connection mechanism to skip HostKeyChecking.
Reference.
Old question that deserves a better answer.
You can prevent interactive prompt without disabling StrictHostKeyChecking (which is insecure).
Incorporate the following logic into your script:
if [ -z "$(ssh-keygen -F $IP)" ]; then
ssh-keyscan -H $IP >> ~/.ssh/known_hosts
fi
It checks if public key of the server is in known_hosts. If not, it requests public key from the server and adds it to known_hosts.
In this way you are exposed to Man-In-The-Middle attack only once, which may be mitigated by:
ensuring that the script connects first time over a secure channel
inspecting logs or known_hosts to check fingerprints manually (to be done only once)
To disable (or control disabling), add the following lines to the beginning of /etc/ssh/ssh_config...
Host 192.168.0.*
StrictHostKeyChecking=no
UserKnownHostsFile=/dev/null
Options:
The Host subnet can be * to allow unrestricted access to all IPs.
Edit /etc/ssh/ssh_config for global configuration or ~/.ssh/config for user-specific configuration.
See http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html
Similar question on superuser.com - see https://superuser.com/a/628801/55163
Make sure ~/.ssh/known_hosts is writable. That fixed it for me.
The best way to go about this is to use 'BatchMode' in addition to 'StrictHostKeyChecking'. This way, your script will accept a new hostname and write it to the known_hosts file, but won't require yes/no intervention.
ssh -o BatchMode=yes -o StrictHostKeyChecking=no user#server.example.com "uptime"
This warning is issued due the security features, do not disable this feature.
It's just displayed once.
If it still appears after second connection, the problem is probably in writing to the known_hosts file.
In this case you'll also get the following message:
Failed to add the host to the list of known hosts
You may fix it by changing owner of changing the permissions of the file to be writable by your user.
sudo chown -v $USER ~/.ssh/known_hosts
Edit your config file normally located at '~/.ssh/config', and at the beggining of the file, add the below lines
Host *
User your_login_user
StrictHostKeyChecking no
IdentityFile ~/my_path/id_rsa.pub
User set to your_login_user says that this settings belongs to your_login_user
StrictHostKeyChecking set to no will avoid the prompt
IdentityFile is path to RSA key
This works for me and my scripts, good luck to you.
Ideally, you should create a self-managed certificate authority. Start with generating a key pair:
ssh-keygen -f cert_signer
Then sign each server's public host key:
ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub
This generates a signed public host key:
/etc/ssh/ssh_host_rsa_key-cert.pub
In /etc/ssh/sshd_config, point the HostCertificate to this file:
HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub
Restart the sshd service:
service sshd restart
Then on the SSH client, add the following to ~/.ssh/known_hosts:
#cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/
The above contains:
#cert-authority
The domain *.example.com
The full contents of the public key cert_signer.pub
The cert_signer public key will trust any server whose public host key is signed by the cert_signer private key.
Although this requires a one-time configuration on the client side, you can trust multiple servers, including those that haven't been provisioned yet (as long as you sign each server, that is).
For more details, see this wiki page.
Do this -> chmod +w ~/.ssh/known_hosts. This adds write permission to the file at ~/.ssh/known_hosts. After that the remote host will be added to the known_hosts file when you connect to it the next time.
With reference to Cori's answer, I modified it and used below command, which is working. Without exit, remaining command was actually logging to remote machine, which I didn't want in script
ssh -o StrictHostKeyChecking=no user#ip_of_remote_machine "exit"
Add these to your /etc/ssh/ssh_config
Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no
Generally this problem occurs when you are modifying the keys very oftenly. Based on the server it might take some time to update the new key that you have generated and pasted in the server. So after generating the key and pasting in the server, wait for 3 to 4 hours and then try. The problem should be solved. It happened with me.
The following steps are used to authenticate yourself to the host
Generate a ssh key. You will be asked to create a password for the key
ssh-keygen -f ~/.ssh/id_ecdsa -t ecdsa -b 521
(above uses the recommended encryption technique)
Copy the key over to the remote host
ssh-copy-id -i ~/.ssh/id_ecdsa user#host
N.B the user # host will be different to you. You will need to type in the password for this server, not the keys password.
You can now login to the server securely and not get an error message.
ssh user#host
All source information is located here:
ssh-keygen
For anyone who finds this and is simply looking to prevent the prompt on first connection, but still wants ssh to strictly check the key on subsequent connections (trust on first use), you can set StrictHostKeyChecking to accept-new in ~/.ssh/config, which will do what you're looking for. You can read more about it in man ssh_config. I strongly discourage disabling key checking altogether.
Run this in host server it's premonition issue
chmod -R 700 ~/.ssh
I had the same error and wanted to draw attention to the fact that - as it just happened to me - you might just have wrong privileges.You've set up your .ssh directory as either regular or root user and thus you need to be the correct user. When this error appeared, I was root but I configured .ssh as regular user. Exiting root fixed it.
This is trying to establish password-less authentication. So, if you try to run that command manually once, it will ask to provide the password there. After entering password, it saves that password permanently, and it will never ask again to type 'yes' or 'no'.
For me the reason is that I have wrong permission on ~/.ssh/known_hosts.
I have no write permission on known_hosts file. So it ask me again and again.
In my case, the host was unkown and instead of typing yes to the question are you sure you want to continue connecting(yes/no/[fingerprint])? I was just hitting enter .
I solve the issue which gives below written error:
Error:
The authenticity of host 'XXX.XXX.XXX' can't be established.
RSA key fingerprint is 09:6c:ef:cd:55:c4:4f:ss:5a:88:46:0a:a9:27:83:89.
Solution:
1. install any openSSH tool.
2. run command ssh
3. it will ask for do u add this host like.
accept YES.
4. This host will add in the known host list.
5. Now you are able to connect with this host.
This solution is working now......