A solution to multiple Raspberry Pi ssh key woes

I have several Raspberry Pi boards, and several SD cards which I swap around depending on what I am doing at the time. I usually can’t be bothered to find and connect up a HDMI display and separate keyboard, so I just connect using ssh from whatever development PC I happen to have to hand. This is very straightforward once you have a ssh client (my personal favourite is MobaXterm – I like it so much that I have recently paid for the professional version.)

There is a problem, though. ssh is designed to be a secure protocol, and is always on the lookout for anything that seems suspicious. In normal networking, an IP address is associated with both a device and its operating system and file data. The Raspberry Pi is a bit of an odd case, though. Each Raspberry Pi board has a built-in MAC address, which is used as a key by a DHCP server to look up which IP address to use. Unfortunately, there is no way to associate data such as ssh keys with the board, as it has no storage of its own; this is all on the SD card. The upshot is that my home network often legitimately has a random combination of IP addresses and ssh keys.

If ssh tries to connect to a known IP address but receives a different ssh key from the one it got before, it makes sense to treat this as a possible security problem and refuse to connect. Most commonly this manifests by the ssh client reporting something like:

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 ECDSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/user/.ssh/known_hosts:3
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
X11 forwarding is disabled to avoid man-in-the-middle attacks.
Permission denied (publickey,password).

This is pretty annoying, especially as it offers no option to proceed anyway. In normal networking this will only usually happen when a machine has been re-installed, so editing the “known_hosts” file to remove the old key is the most appropriate thing to do. In the Raspberry Pi case, though, this just means that I’ll see the same problem again next time I change cards. The web seems full of suggestions about how to delete a line from the known_hosts file, but it’s hard to find any other answers. It’s not even particularly easy to edit the file to add the new key, as the “helpful” message above does not include it!

Eventually, though, when faced with this problem yet again today, I have found a much better solution. A long way down this Q&A page was the hint. ssh installations usually include some tools to create and manage keys, and the one we want in this case is ssh-keyscan. The example code given did not work straight away, but removing one of the options helped. Now whenever I see this message when connecting to one of my Raspberry Pis I can just type

ssh-keyscan >> ~/.ssh/known_hosts

This asks the machine at the supplied IP address for its keys, and adds them to the end of the known_hosts file, so that ssh connections will now work to both the old and new board/card combinations. You will need probably need to replace the IP address with your own, of course.

Big sigh of relief :)


  1. You could also consider a standardising on one SSH public/private host key pair across all your raspis (at least, all the dev/ experimental/ nonisecurity-critical ones.) On most distros you should find these as 2 files in /etc/ssh/id_* or similar (might be /etc/ssh2/… on some systems) — take a copy of both onto your build system to use as a master, and copy them on to your SD card whenever you’ve made a new one.

  2. From RPi forum:

    If you never connect outside your LAN then known_hosts is a pointless pain. It can be eliminated by updating /etc/ssh/ssh_config with

    Host 192.168.1.*
    StrictHostKeyChecking no

Leave a Reply

Your email address will not be published. Required fields are marked *