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)
Related
I want to transfer a few files weekly from mainframe to a Linux server running RedHat using a batch (JCL) job using FTPS.
Linux server is configured with vsftpd. Is it possible to send file from mainframe to linux using FTPS?
Getting this error while transferring the file from mainframe to Linux.
EZA1736I FTP
EZY2640I Using 'SYS1.TCPPARMS(FTPDATA)' for local site configuration parameters.
EZA1450I xxx FTP CS xxx
EZA1456I Connect to ?
EZA1736I host_name
EZA1554I Connecting to: host_name xxx.xxx.xxx.xxx port: 21.
220 (vsFTPd 2.0.5)
EZA1701I >>> AUTH TLS
234 Proceed with negotiation.
EZA2897I Authentication negotiation failed
EZA1534I *** Control connection with host_name dies.
EZA1457I You must first issue the 'OPEN' command
EZA1460I Command:
EZA1618I Unknown command: 'Atul'
EZA1619I For a list of the available commands, say HELP
EZA1460I Command:
EZA1736I Summer#123
EZA1618I Unknown command: 'Monsoon#123'
EZA1460I Command:
EZA1736I cd /home/Atul/
EZA1457I You must first issue the 'OPEN' command
From your log you seem to be able to set up an unsecured connection to the FTP server. That's good.
EZA2897I Authentication negotiation failed indicates that the TLS-handshake did not complete successfully. Either the partners could not find a common TLS-version and/or ciphersuite or (that's the point I'd examine first) the certificate provided by the FTPs-server isn't trusted by the client user. To be sure you would have to capture and examine a TCP- or TLS-trace.
In a first step I would check the certificate provided by the FTP server and compare it to the trusted certificates in your security manager. In the case of RACF you would have to examine SITE-certificates and/or certificates in the user's keyring.
Yes, sending from the mainframe using FTPS to VSFTP is certainly possible. Both the client (z/OS in this case) and server (Linux in this case) need to agree on the encryption method to be used and I believe by default, z/OS has to trust the certificate for the server, which may involve importing the certificate bundle to a key ring that the batch job has access to. The job not having access to a keyring that trusts the chain for the server certificate would be my first guess.
I don't have experience with setting up the RACF keyring things, but I can say that people do successfully send us data every day from z/OS to our Linux server via FTPS.
I have created ssh keys and registered my public key on the target host under .ssh/.authorized_keys.
And it also generally works. I just observe a strange behavior: When I try to login the first time in the morning, I see "Server refused our key" and get forced to enter my passphrase. Any consecutive attempts then work fine and I see in the console output that it's registering with my key.
If I don't log in for a longer time, then a new login would show the same behavior as above and I get forced to enter my passphrase.
So I was wondering: Is there maybe a configurable value that prevents me registering with my key after certain time that I can just increase or deactivate?
You may find your answer here. Some servers are configured to verify the hosts before they can login for the first time.
https://unix.stackexchange.com/questions/42643/ssh-key-based-authentication-known-hosts-vs-authorized-keys
We can make SSH automatically write new host keys to the known_hosts file by setting StrictHostKeyChecking to “no” in the ~/.ssh/config file.
StrictHostKeyChecking=no
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.
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 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?