0

Recently, after some time, I have tried to login to my ssh server on the LAN, and I got this warning:

$ ssh user@local.server.hostname
Warning: Permanently added the RSA host key for IP address '192.168.1.4' to the list of known hosts.

I took a look to the following post on SO: https://stackoverflow.com/questions/9299651/warning-permanently-added-to-the-list-of-known-hosts-message-from-git But I don't think that this is due to the ssh client that doesn't check the known_hosts file (I guess it checks it in my case, and I am not running Windows).

Here is the known_hosts file, and I have found that I have two lines of the same public key, but different hostnames/IPs:

$ cat ~/.ssh/known_hosts
local.server.hostname,192.168.1.3 ssh-rsa ...Here it goes the public key...
192.168.1.4 ssh-rsa ...Here it goes the same public key (as for the local.server.hostname,192.168.1.3 entry above)...

I am sure the two public keys are equal (I have checked the fingerprint of both with the command echo "here I pasted the public key" | base64 -D | md5, which I ran for each entry of known_hosts). Otherwise I would have seen a "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED".

Now, I have a local network with DHCP, so the server gets assigned an IP and sometimes it could get assigned a different one.

I guess this is the primary reason why I had this warning: Server IP changed (from 192.168.1.3, first line of known_hosts, to 192.168.1.4), but as the public key remained the same and the public key was already trusted by my ssh client because there was already an entry for local.server.hostname,192.168.1.3 in known_hosts, the ssh client showed me the warning, but added the entry for 192.168.1.4 without asking me for confirmation.

Is that correct? The only thing that comes in mind is: why then the client added another entry instead of just modifying the already existing one, such as in the following way:

local.server.hostname,192.168.1.3,192.168.1.4 ssh-rsa ...public key...

Why two entries for the same public key?

2

Indeed, the reason is your DHCP environment which assigned a new IP address to your server.

Whenever ssh connects to an IP address that it doesn't have in its known_hosts file it will react according to your StrictHostKeyChecking config, see man ssh_config:

 StrictHostKeyChecking
         If this flag is set to “yes”, ssh(1) will never automatically add host keys to the ~/.ssh/known_hosts file,
         and refuses to connect to hosts whose host key has changed.  This provides maximum protection against trojan
         horse attacks, though it can be annoying when the /etc/ssh/ssh_known_hosts file is poorly maintained or when
         connections to new hosts are frequently made.  This option forces the user to manually add all new hosts.  If
         this flag is set to “no”, ssh will automatically add new host keys to the user known hosts files.  If this
         flag is set to “ask”, new host keys will be added to the user known host files only after the user has con-
         firmed that is what they really want to do, and ssh will refuse to connect to hosts whose host key has
         changed.  The host keys of known hosts will be verified automatically in all cases.  The argument must be
         “yes”, “no”, or “ask”.  The default is “ask”.

As you see ssh makes no attempt to match/update any known keys to the new IP address (which would probably be considered a security risk). Hence the different lines matching different IP addresses to the same host key.

If the DHCP server would now assign the old address to another server and you'd try to ssh to it it'll likely have a different host key and ssh connection will be refused. To avoid such cases you may want to check if you can switch to statically-assigned IP addresses (some DHCP servers offer support for static mappings themselves, with no changes on the clients).

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.