Hello,
I am having this issue regarding at one of our servers. Let me give a little insight on it, i was trying to do ssh to one of our linux server and i was presnted with the following error which i am totally aware of and fully undertands it. Quote:
1. First i deleted the entry for this server from my known_hosts file on client and then tried the ssh so that its a new connection. But to my surprise the server is not offering the Public HOst Key to accept but is asking for root password for the server. 2. I also tried by setting the StrictHostKeyChecking option to no but even that also did not work. So my questions here a) Why server is not offering the new Public Key and asking me "If you want to continue(yes/no)". b) Afetr removing the server Public Key from known_hosts file it starts asking for password but if the server Public Key is not removed then it does not ask for password. So if I understand correctly known_hosts file has nothing to with password less authentication. Any help would be greatly appreciated !! How does SSH client verifies the Server's identity for the very first time before it has been added to known_hosts file.Sorry to say that it might sound little stupid but it is troubling me alot and i have not been able to find the correct precise answer even after intense googling. What i mean to ask is that how exactly a client comes to know that to the SSH server it has initiated connection is what it says it is. A Man in the Middle system can impersonate the actual SSH server and present its own public key to the client and then client will add it to its known_hosts list. I know it might sound bit silly or stupid but i am having hard in figuring out How exactly a SSH cleint verifies the SSH server's identity for the very first time when it initiates the connection before it has already added the entry to its known_hosts file. I have done quite intense googling but i have not still found a precise satisfactory answer, so if someone can please tell me how exactly the clinet comes to know that it is indeed talking to the server to whom it should. |
a) Don't know, but try renaming known_hosts temporarily, in case another entry is causing problems
b) For passwordless login, the public key of the client must be stored in ~/.ssh/authorized_keys for the user you're logging in as on the server. |
it puts the onus on you. By default, you need to manually accept the identity key the server provides. There's clearly no formal basis for knowing a server is legit (compared to trusted root CAs in the HTTPS world) so you have to arbitrarily draw a line yourself by saying you trust them on the first connect.
|
The message means exactly what it says, and you should treat it seriously. Each ssh host generates a random string which is its calling-card, and it stores this in .ssh/known_hosts. (Not authorized_keys, which is part of RSA-key based authentication.)
Unless there is a damm good reason why the key is changed, there might be a "man in the middle." It could be innocuous, it could be explainable, it could be innocent. But there's a reason why SSH is screaming at you about this, and you should heed it. A loud bell has gone off. Don't silence it: find out why it is ringing. (That's what it's there for.) |
Quote:
|
I think that the designers didn't want to make it that easy.
I presume that you also have an authorized-keys entry which permits password-free login. My understanding is that the keys are tied to the originating host. |
SSH Issue - REMOTE HOST IDENTIFICATION HAS CHANGED! Reply to Thread
Try using the below command
# ssh-keygen -R {server-ip-address} #service network restart Now try to connect to Remote host.. you will be succeeded. |
Quote:
Please don't post advice that's incorrect/misleading, and don't re-open old threads to do it. |
All times are GMT -5. The time now is 12:55 AM. |