[SOLVED] Cannot access over SSH - Remote Host ID changed

Setup, Configuration and Use Beginners
1

  • Platform information:

    • Hardware: Raspberry Pi 3B+
    • OS: Mac
    • Java Runtime Environment: don’t know
    • openHAB version: 2.3

  • Issue of the topic:
    After a replacing a SD card I reinstalled OpenHAB on my RPi. I believe it installed correctly (as http://openhabianpi:8080/start/index was accessed correctly), however when wishing to connect remotely through SSH (using terminal on a mac) I am unable to access. The terminal window displays message that remote host has changed! See attached for full message in window…
    Please could a remedy be found easily here?
    Please help me. Thanks

  • If logs where generated please post these here using code fences:37

2

Navigate to the folder /Users/danielwatson/.ssh and edit known_hosts and delete all of the host entries you have for openhabian and save the file. You’ll be able to ssh once again.

3

Hi Garry.
Thanks for your prompt reply.
How do identify the host entries that are for openhabian?
… actually I just deleted all the text assocated witht he IP address of the RPi… and it seems to have worked…

Thank you

4

Just to explain what happened, when you install the operating system, it generates a new and unique key. One of the things that ssh’s use of keys does is to make sure that you are talking to the actual computer you think you are and not some impostor. So when it saw that the key was different for host 192.168.1.117 from what it was previously, it won’t let you connect. Since you know that the key changed because you rebuilt the machine, you know that it is in fact safe to connect to the host.

To correct the problem, the ssh error message actually tells you exactly what line in known_hosts is the problem file. In the future, you just need to delete the line indicated from the file indicated. In this case, line 6 from /Users/danielwatson/.ssh/known_hosts.

1 Like
5

Rich.
Thank you very much for the explanation, although to be honest, I not exactly clear on all the details in your message. I have learnt that the “…:6” means line 6.

So in layman’s terms… The operating system (OH on RPi) passes a key to the SSH running on my mac. Each time the connection between the RPi and Mac is made it looks for a code in the “known_hosts” file. If the code is not correct connection is not made.
The code was incorrect, i assume as a different code is generated for each installation of OH.
Have I got that right? (apologies for my ignorance!)

Thanks
Dan

6

I like to think of your Mac known_hosts file as a collection of fingerprints for different SSH servers you have successfully connected with, rebuilding the Pi created a new fingerprint and the Mac detected that difference.

7

Mostly right. It isn’t the installation of OH that caused the generation of a new code. It is the installation of the new operating system. Or more specifically, the installation/reinstallation of SSH server software is what causes the generation of the “code”. When you reinstalled raspbian, you installed a new instance of the ssh server so you got a new “code”.

The “code” itself is a little bit more than just a code. It uses public key cryptography. With this type of cryptography there is a public key and a private key. If you encrypt something using the public key, only the private key can decrypt the message. If you encrypt something using the private key, only the public key can decrypt it.

So in this case, the “code” is the public key. The server encrypts a message using their private key and if you can decrypt it using the key in known_hosts you know that you can only be talking to that server as no other server will have the private key.

It’s actually a collection of the public keys of all the servers you have connected to. When you connect to a server for the first time and you get that message:

The authenticity of host 'argus.koshak.net (10.10.1.127)' can't be established.
ECDSA key fingerprint is SHA256:blahblahblahblah
Are you sure you want to continue connecting (yes/no)?

When you select “yes” that will add that host’s public key, and some other stuff, to the known_hosts file so next time it can do the test described above to ensure there is no impostor. So it is important that you know that you are talking to your machine when you first connect using SSH. That’s no big deal with machines you own and control but it becomes more interesting when you are working with cloud servers and the like.

Note that this is similar to how HTTPS works, though the way you get and know you can trust the public key from the server you are talking to is more complicated. It’s a complicated but very interesting topic.

1 Like