When I am checking a remote host is active or not by ssh, an warning message shown as below always pops up on the screen. Though it is a normal progress in my program but it really affect the user experience by seeing it on the screen. Is there any way to hide it or redirect it to other files?
Warning message:
##########################################################
# 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)!
Instead of ignoring it, investigate why the host key of the remote host has changed. If it's for a legitimate reason (another machine got the old IP address (and you actually want to connect to the new machine), or the host keys were re-generated for some reason), then delete the corresponding line from ~/.ssh/known_hosts.
Related
For the history, I have a local VM (Virtualbox) with OS debian and in this VM I have been developed a Web application. I log in with ssh protocol.
Today, I'm facing a strange troubleshooting. I tried to connect with ssh to my local VM and got the following message:
###########################################################
# 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
SHA256:_______________________________________.
Please contact your system administrator.
Add correct host key in /Users/_____/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/______/.ssh/known_hosts:5
RSA host key for 192.168.1.6 has changed and you have requested strict checking.
Host key verification failed.
I understand that the fingerprint of my local VM has been changed, and i wonder, if it is possible to change the public fingerprint by itself.
I'm trying to understand if there is man in the middle.
Thank you for your time :)
Maybe this can help you https://superuser.com/questions/421997/what-is-a-ssh-key-fingerprint-and-how-is-it-generated
check if exist other machine with the same IP (maybe static IP), you can use "arping" for that
(I post as answer because I can't comment)
I have a misconfigured heroku website. It shows error 104 (Read Error: Connection reset by peer) upon typing its URL and hitting enter. But subsequently refreshing the URL a couple of times makes the URL load correctly (some kind of fallback kicks in? - not that I knowingly configured any). The URL is http://damadam.in/ (it's a naked domain).
I bought this domain from godaddy. In Godaddy's control panel where I have the DNS Zone file, the host www points to damadam.herokuapp.com (under CName). http://damadam.in is set to forward to http://www.damadam.in. Lastly, in my heroku control panel both http://damadam.in and http://www.damadam.in have damadam.herokuapp.com as the DNS target (could this last configuration be the problem)?
Can someone help me properly set this thing up?
This is not a http response code, but rather an error number indicating something was wrong with the connection.
"Connection reset by peer" means that, on the route from your computer to the final destination, a node decided to forcefully stop and reset the connection. On a configuration level I don't think you will be able to do much about this. If there was some kind of DNS misconfiguration, you would not see a read error, but a DNS Error instead.
Make sure that your local network is stable (e.g. connect to your modem with an ethernet cable, rather than through wifi). If this connection is stable, try again at a later date. Connections between nodes can break, and in some cases not all traffic might be able to reach the intended destination. If behaviour persists through a greater length of time, contact your host, in this case Godaddy, and ask them to look into this problem. It might be just a faulty piece of equipment
The following warning shows up everytime when I login a remote server using ssh haifzhan#remote_server, anyone knows why and how to fix it?
Warning: the RSA host key for 'HOSTNAME' differs from the key for the IP address 'IP ADDRESS'
Offending key for IP in /home/haifzhan/.ssh/known_hosts:15
Matching host key in /home/haifzhan/.ssh/known_hosts:19
Are you sure you want to continue connecting (yes/no)?
My OS is centOS6
Delete "known_hosts" and log in again. It will ask you to reconfirm.
Or just remove line 15 using a text editor.
This type of problem occurs when the host is re-keyed (as in when a new OS may be loaded or when the server admin decides it's time to generate another key for security reasons). Or when some new machine grabs the IP address that you were previously using for another machine.
I work on a network where the systems at an IP address will change frequently. They are moved on and off the workbench and DHCP determines the IP they get.
It doesn't seem straightforward how to disable host key caching/checking so that I don't have to edit ~/.ssh/known_hosts every time I need to connect to a system.
I don't care about the host authenticity, they are all on the 10.x.x.x network segment and I'm relatively certain that nobody is MITM'ing me.
Is there a "proper" way to do this? I don't care if it warns me, but halting and causing me to flush my known_hosts entry for that IP every time is annoying and in this scenario it does not really provide any security because I rarely connect to the systems more than once or twice and then the IP is given to another system.
I looked in the ssh_config file and saw that I can set up groups so that the security of connecting to external machines could be preserved and I could just ignore checking for local addresses. This would be optimal.
From searching I have found some very strong opinions on the matter, ranging from "Don't mess with it, it is for security, just deal with it" to "This is the stupidest thing I have ever had to deal with, I just want to turn it off" ... I'm somewhere in the middle. I just want to be able to do my job without having to purge an address from the file every few minutes.
Thanks.
This is the configuration I use for our ever-changing EC2 hosts:
maxim#maxim-desktop:~$ cat ~/.ssh/config
Host *amazonaws.com
IdentityFile ~/.ssh/keypair1-openssh
IdentityFile ~/.ssh/keypair2-openssh
User ubuntu
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
This disables host confirmation StrictHostKeyChecking no and also uses a nice hack to prevent ssh from saving the host identify to a persistent file UserKnownHostsFile /dev/null note that as an added value I've added the default user with which to connect to the host and the option to try several different identify private keys.
Assuming you're using OpenSSH, I believe you can set the
CheckHostIP no
option to prevent host IPs from being checked in known_hosts. From the man page:
CheckHostIP
If this flag is set to 'yes', ssh(1)
will additionally check the host IP
address in the known_hosts file. This
allows ssh to detect if a host key
changed due to DNS spoofing. If the
option is set to 'no', the check will
not be executed. The default is
'yes'.
This took me a while to find. The most common use-case I've seen is when you've got SSH tunnels to remote networks. All the solutions here produced warnings which broke my Nagios scripts.
The option I needed was:
NoHostAuthenticationForLocalhost yes
Which, as the name suggests also only applies to localhost.
Edit your ~/.ssh/config
nano ~/.ssh/config (if there wasn't one already, don't worry, nano will create a new file)
Add the following config:
Host 192.168.*
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
If you want to disable this temporarily or without needing to change your SSH configuration files, you can use:
ssh -o UserKnownHostsFile=/dev/null username#hostname
Since every other answer explains how to disable the key checking, here are two ideas that preserve the key checking, but avoid the problem:
Use hostnames. This is easy if you control the DHCP server and can assign proper names. After that you can just use the known hostnames, the changing ips don't matter.
Use hostnames. Even if you don't control the DHCP server, you can use a service like avahi, which will broadcast the name of the server in our local network. It takes care of solving collisions and other issues.
Use host key signing. After you built a machine, sign it with a local CA (you don't need a global trusted CA for that). After that, you don't need to trust each host separately on your machine. It's enough that you trust the signing CA in the known_hosts file. More information in the ssh-keygen man page or at many blog posts (https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu)
I am doing ssh to server x1.example.com from a laptop sometimes from outside and sometimes from lan. From lan I just say
ssh karl#x1
and from wan:
ssh karl#x1.example.com
But from lan I get always a warning: remote host identification has changed.
I can delete the other key in the known_hosts file each time, but I was wondering if there is a better solution.
I am hesitating to turn the key verification off, because this would be less secure. But getting a warning all the time is also unsecure (because I ignore such warnings all the time then)
In known_hosts file you can list several names and even IP's for one key, for example:
x1,x1wan.example.com,192.168.0.134,23.41.51.23 ssh-rsa AAAA/bunch/of/gibberish/looking/data/==
But it is not your problem here. If you have a warning that host identification has changed it really means that. It means that between a moment of your first connection to this host from lan and now, somebody regenerated a host key for this host, for example while reinstalling the OS. Or that you have a man-in-the-middle attack.
Confirm with your admin that a host was reinstalled and host key regenerated and then remove old key from your known_hosts file. Next time you connect you'll add a new, correct key to known_hosts file and this warning will go away.
I think it is actually one name, technically.
Assign a second host name (maybe via your hosts file) to access your server from the WAN: E.g.:
ssh karl#x1wan.example.com
I access a server via ssh with two different names (same IP) with no warnings. E.g.: name1.example.com and name2.example.com
Thank you very much for your answers.
Sorry folks, I lost my cookie based login and cannot rate or edit anymore. Your questions helped me to get around the problem when I change from LAN to WAN. I regard this question as solved.
But now I see the problem goes even deeper because I also have 2 hosts on the same IP, and the IP also changes, which I am covering (from my new account which I cannot loose anymore) in a new question with more details:
How to handle ssh host key verification with 2 different hosts on the same (but changing) IP address?