Hi Josh. This warning is real and important, but in this case you should expect the error and work around it.
How do I explain it in as few words as possible? Obviously I can’t:
When you connect to a remote ssh server for the first time, usually you have to accept the fingerprint of the ssh server as good without any means to check that it is actually correct. When that ssh server fingerprint is accepted by you as as good, then it is stored along on your system and paired with the IP address of the server. The next time you connect by ssh to that IP address, your system checks the fingerprint and IP against its own copy, decides to trust it, and lets you connect without hassle.
If you are connecting to a server on the Internet and you get that warning it means that the fingerprint is different and something has changed (new server software, MITM attack, etc.) and it is a cause for concern.
However, we are doing this one-to-one directly between your computer and the Reach hotspot so there shouldn’t be a MITM attack happening.
Now, when you connect to any Reach hotspot, Reach always has the same IP address (192.168.42.1), but every Reach generates itself a different ssh server fingerprint. So if you have previously connected to one Reach through its hotspot at IP address 192.168.42.1, and then you switch over and connect to a different Reach though its hotspot at IP address 192.168.42.1, well you are going to get 2 different fingerprints which appear to come from the same IP address, and that will trigger the warning that you see above.
I hope that makes at least a bit of sense why the warning is good and also why the warning should be expected in this case, and then why you should be able to confidently decide to disable the warning for this one time.
One way to disable the warning is to remove the previously stored fingerprint for that IP address using ssh-keygen like this:
ssh-keygen -f ~/.ssh/known_hosts -R 192.168.10.1
Another way is do delete the offending line from the ~/.ssh/known_hosts file.
Say that you managed 2 routers via ssh that were in different offices and they had the same default IP address as each other because they were the same model and same brand. You would experience the same warning and workaround when working with one and then the other. It is not a normal thing to have to do this procedure, but it is what must be done. Of course there will be other ways to avoid the error, but I believe this to be the most simple way. And we don’t want to diverge to far from the task at hand or get into a big discussion about best practices and security in general.
LOL 