问题
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?
回答1:
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.
回答2:
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)
回答3:
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
回答4:
Make sure ~/.ssh/known_hosts
is writable. That fixed it for me.
回答5:
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"
回答6:
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.
回答7:
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
回答8:
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.
回答9:
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"
回答10:
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.
回答11:
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.
回答12:
Run this in host server it's premonition issue
chmod -R 700 ~/.ssh
回答13:
Add these to your /etc/ssh/ssh_config
Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no
回答14:
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.
回答15:
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......
来源:https://stackoverflow.com/questions/3663895/ssh-the-authenticity-of-host-hostname-cant-be-established